Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [PATCH] mm: implement swap prefetching | Date | Wed, 8 Feb 2006 16:33:11 +1100 |
| |
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |