|
Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 Newsgroups: gmane.linux.kernel, gmane.linux.kernel.mm Date: 2005-11-03 15:51:11 GMT (3 years, 34 weeks, 5 days, 9 hours and 10 minutes ago) On Thu, 3 Nov 2005, Arjan van de Ven wrote: > On Thu, 2005-11-03 at 07:36 -0800, Martin J. Bligh wrote: > > >> 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. > > > > Sigh. OK, tell me how you're going to fix kernel stacks > 4K please. > > with CONFIG_4KSTACKS :) 2-page allocations are _not_ a problem. Especially not for fork()/clone(). If you don't even have 2-page contiguous areas, you are doing something _wrong_, or you're so low on memory that there's no point in forking any more. Don't confuse "fragmentation" with "perfectly spread out page allocations". Fragmentation means that it gets _exponentially_ more unlikely that you can allocate big contiguous areas. But contiguous areas of order 1 are very very likely indeed. It's only the _big_ areas that aren't going to happen. This is why fragmentation avoidance has always been totally useless. It is - only useful for big areas - very hard for big areas (Corollary: when it's easy and possible, it's not useful). Don't do it. We've never done it, and we've been fine. Claiming that fork() is a reason to do fragmentation avoidance is invalid. Linus |
|
|