On Thu, Jul 04, 2013 at 03:36:38PM -0400, Johannes Weiner wrote:
> I was going for the opposite conclusion: that it does not matter
> whether memory is accessed privately or in a shared fashion, because
> there is no obvious connection to its access frequency, not to me at
> least.
There is a
On Thu, Jul 04, 2013 at 03:36:38PM -0400, Johannes Weiner wrote:
> On Thu, Jul 04, 2013 at 10:23:56AM +0100, Mel Gorman wrote:
> > On Wed, Jul 03, 2013 at 05:56:54PM -0400, Johannes Weiner wrote:
> > > On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
> > > > Ideally it would be possible
On Thu, Jul 04, 2013 at 03:36:38PM -0400, Johannes Weiner wrote:
On Thu, Jul 04, 2013 at 10:23:56AM +0100, Mel Gorman wrote:
On Wed, Jul 03, 2013 at 05:56:54PM -0400, Johannes Weiner wrote:
On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
Ideally it would be possible to
On Thu, Jul 04, 2013 at 03:36:38PM -0400, Johannes Weiner wrote:
I was going for the opposite conclusion: that it does not matter
whether memory is accessed privately or in a shared fashion, because
there is no obvious connection to its access frequency, not to me at
least.
There is a
On Thu, Jul 04, 2013 at 10:23:56AM +0100, Mel Gorman wrote:
> On Wed, Jul 03, 2013 at 05:56:54PM -0400, Johannes Weiner wrote:
> > On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
> > > Ideally it would be possible to distinguish between NUMA hinting faults
> > > that are private to a
On 07/04/2013 05:23 AM, Mel Gorman wrote:
I think that dealing with this specific problem is a series all on its
own and treating it on its own in isolation would be best.
Agreed, lets tackle one thing at a time, otherwise we will
(once again) end up with a patch series that is too large
to
On Wed, Jul 03, 2013 at 05:56:54PM -0400, Johannes Weiner wrote:
> On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
> > Ideally it would be possible to distinguish between NUMA hinting faults
> > that are private to a task and those that are shared. This would require
> > that the last
On Wed, Jul 03, 2013 at 05:56:54PM -0400, Johannes Weiner wrote:
On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
Ideally it would be possible to distinguish between NUMA hinting faults
that are private to a task and those that are shared. This would require
that the last task
On 07/04/2013 05:23 AM, Mel Gorman wrote:
I think that dealing with this specific problem is a series all on its
own and treating it on its own in isolation would be best.
Agreed, lets tackle one thing at a time, otherwise we will
(once again) end up with a patch series that is too large
to
On Thu, Jul 04, 2013 at 10:23:56AM +0100, Mel Gorman wrote:
On Wed, Jul 03, 2013 at 05:56:54PM -0400, Johannes Weiner wrote:
On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
Ideally it would be possible to distinguish between NUMA hinting faults
that are private to a task and
On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
> Ideally it would be possible to distinguish between NUMA hinting faults
> that are private to a task and those that are shared. This would require
> that the last task that accessed a page for a hinting fault would be
> recorded which
Ideally it would be possible to distinguish between NUMA hinting faults
that are private to a task and those that are shared. This would require
that the last task that accessed a page for a hinting fault would be
recorded which would increase the size of struct page. Instead this patch
Ideally it would be possible to distinguish between NUMA hinting faults
that are private to a task and those that are shared. This would require
that the last task that accessed a page for a hinting fault would be
recorded which would increase the size of struct page. Instead this patch
On Wed, Jul 03, 2013 at 03:21:34PM +0100, Mel Gorman wrote:
Ideally it would be possible to distinguish between NUMA hinting faults
that are private to a task and those that are shared. This would require
that the last task that accessed a page for a hinting fault would be
recorded which would
14 matches
Mail list logo