From: Con Kolivas <kernel@kolivas.org>
To: Paul Jackson <pj@sgi.com>
Cc: nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, akpm@osdl.org, ck@vds.kolivas.org
Subject: Re: [PATCH] mm: implement swap prefetching
Date: Wed, 8 Feb 2006 16:33:11 +1100 [thread overview]
Message-ID: <200602081633.12072.kernel@kolivas.org> (raw)
In-Reply-To: <200602081606.19656.kernel@kolivas.org>
On Wed, 8 Feb 2006 04:06 pm, Con Kolivas wrote:
> On Wed, 8 Feb 2006 03:46 pm, Paul Jackson wrote:
> > Con, responding to Nick:
> > > > It introduces global cacheline bouncing in pagecache allocation and
> > > > removal and page reclaim paths, also low watermark failure is quite
> > > > common in normal operation, so that is another global cacheline write
> > > > in page allocation path.
> > >
> > > None of these issues is going to remotely the target audience. If the
> > > issue is how scalable such a change can be then I cannot advocate
> > > making the code smart and complex enough to be numa and cpuset aware..
> > > but then that's never going to be the target audience. It affects a
> > > particular class of user which happens to be quite a large population
> > > not affected by complex memory hardware.
> >
> > How about only moving memory back to the Memory Node (zone) that it
> > came from? And providing some call that Christoph Lameters migration
> > code can call, to disable or fix this up, so you don't end up bringing
> > back pages on their pre-migration nodes?
>
> Sounds good, and this is what I was hoping to be able to do; first I need
> to see the best time and place to get this information (and learn some more
> about the code).
Actually it's looking an awful lot like I should just use one thread per pgdat
and have per node data. Given that, I should probably just make this a task
for kswapd since that is what they already are - and the name isn't wrong
either.
Cheers,
Con
WARNING: multiple messages have this Message-ID (diff)
From: Con Kolivas <kernel@kolivas.org>
To: Paul Jackson <pj@sgi.com>
Cc: nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, akpm@osdl.org, ck@vds.kolivas.org
Subject: Re: [PATCH] mm: implement swap prefetching
Date: Wed, 8 Feb 2006 16:33:11 +1100 [thread overview]
Message-ID: <200602081633.12072.kernel@kolivas.org> (raw)
In-Reply-To: <200602081606.19656.kernel@kolivas.org>
On Wed, 8 Feb 2006 04:06 pm, Con Kolivas wrote:
> On Wed, 8 Feb 2006 03:46 pm, Paul Jackson wrote:
> > Con, responding to Nick:
> > > > It introduces global cacheline bouncing in pagecache allocation and
> > > > removal and page reclaim paths, also low watermark failure is quite
> > > > common in normal operation, so that is another global cacheline write
> > > > in page allocation path.
> > >
> > > None of these issues is going to remotely the target audience. If the
> > > issue is how scalable such a change can be then I cannot advocate
> > > making the code smart and complex enough to be numa and cpuset aware..
> > > but then that's never going to be the target audience. It affects a
> > > particular class of user which happens to be quite a large population
> > > not affected by complex memory hardware.
> >
> > How about only moving memory back to the Memory Node (zone) that it
> > came from? And providing some call that Christoph Lameters migration
> > code can call, to disable or fix this up, so you don't end up bringing
> > back pages on their pre-migration nodes?
>
> Sounds good, and this is what I was hoping to be able to do; first I need
> to see the best time and place to get this information (and learn some more
> about the code).
Actually it's looking an awful lot like I should just use one thread per pgdat
and have per node data. Given that, I should probably just make this a task
for kswapd since that is what they already are - and the name isn't wrong
either.
Cheers,
Con
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-02-08 5:32 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-06 23:28 [PATCH] mm: implement swap prefetching Con Kolivas
2006-02-06 23:28 ` Con Kolivas
2006-02-07 0:38 ` Andrew Morton
2006-02-07 0:38 ` Andrew Morton
2006-02-07 1:29 ` Con Kolivas
2006-02-07 1:29 ` Con Kolivas
2006-02-07 1:32 ` [ck] " Con Kolivas
2006-02-07 1:32 ` Con Kolivas
2006-02-07 1:39 ` Andrew Morton
2006-02-07 1:39 ` Andrew Morton
2006-02-07 1:37 ` Bernd Eckenfels
2006-02-08 3:29 ` [PATCH] mm: implement swap prefetching v21 Con Kolivas
2006-02-08 3:49 ` [ck] " Con Kolivas
2006-02-08 3:49 ` Con Kolivas
2006-02-07 3:08 ` [PATCH] mm: implement swap prefetching Nick Piggin
2006-02-07 3:08 ` Nick Piggin
2006-02-07 3:29 ` Nick Piggin
2006-02-07 3:29 ` Nick Piggin
2006-02-07 4:02 ` Con Kolivas
2006-02-07 4:02 ` Con Kolivas
2006-02-07 5:00 ` Nick Piggin
2006-02-07 5:00 ` Nick Piggin
2006-02-07 6:02 ` Con Kolivas
2006-02-07 6:02 ` Con Kolivas
2006-02-07 6:51 ` Nick Piggin
2006-02-07 6:51 ` Nick Piggin
2006-02-07 10:54 ` Con Kolivas
2006-02-07 10:54 ` Con Kolivas
2006-02-07 17:14 ` Andrew Morton
2006-02-07 17:14 ` Andrew Morton
2006-02-07 20:34 ` Marcelo Tosatti
2006-02-07 22:39 ` Andi Kleen
2006-02-08 4:46 ` Paul Jackson
2006-02-08 4:46 ` Paul Jackson
2006-02-08 5:06 ` Con Kolivas
2006-02-08 5:06 ` Con Kolivas
2006-02-08 5:13 ` Paul Jackson
2006-02-08 5:13 ` Paul Jackson
2006-02-08 5:33 ` Con Kolivas [this message]
2006-02-08 5:33 ` Con Kolivas
-- strict thread matches above, loose matches on Subject: below --
2006-02-20 13:44 [PATCH] mm: Implement " Con Kolivas
2006-02-20 19:08 ` Mattia Dongili
2006-02-20 20:47 ` Con Kolivas
2006-02-20 20:58 ` Con Kolivas
2006-02-20 23:45 ` Michal Piotrowski
2006-02-24 11:23 Con Kolivas
2006-02-24 11:23 ` Con Kolivas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200602081633.12072.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--cc=ck@vds.kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.