Messages in this thread | | | Date | Thu, 03 Nov 2005 14:21:50 +1100 | From | Nick Piggin <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
Martin J. Bligh wrote:
>>What can we do reasonably sanely? I think we can drive about 16GB of >>highmem per 1GB of normal fairly well. So on your 1TB system, you >>should be able to unplug 960GB RAM. > > > I think you need to talk to some more users trying to run 16GB ia32 > systems. Feel the pain. >
OK, make it 8GB then.
And as a bonus we get all you IBM guys back on the case again to finish the job that was started on highmem :)
And as another bonus, you actually *have* the capability to unplug memory or use hugepages exactly the size you require, which is not the case with the frag patches.
>>But if you can reclaim your ZONE_RECLAIMABLE, then you could reclaim >>it all and expand your normal zones into it, bottom up. > > > Can we quit coming up with specialist hacks for hotplug, and try to solve > the generic problem please? hotplug is NOT the only issue here. Fragmentation > in general is. >
Not really it isn't. There have been a few cases (e1000 being the main one, and is fixed upstream) where fragmentation in general is a problem. But mostly it is not.
Anyone who thinks they can start using higher order allocations willy nilly after Mel's patch, I'm fairly sure they're wrong because they are just going to be using up the contiguous regions.
Trust me, if the frag patches were a general solution that solved the generic fragmentation problem I would be a lot less concerned about the complexity they introduce. But even then it only seems to be a problem that a very small number of users care about.
Anyway I keep saying the same things (sorry) so I'll stop now.
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |