Messages in this thread | | | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 | From | Arjan van de Ven <> | Date | Thu, 03 Nov 2005 17:20:32 +0100 |
| |
On Thu, 2005-11-03 at 07:51 -0800, Linus Torvalds wrote: > > 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.
agreed for the general case. There are some corner cases that you can trigger deliberate in an artifical setting with lots of java threads (esp on x86 on a 32Gb box; the lowmem zone works as a lever here leading to "hyperfragmentation"; otoh on x86 you can do 4k stacks and it's gone mostly)
> 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.
yup. only possible exception is the leveraged scenario .. thank god for 64 bit x86-64.
(and in the leveraged scenario I don't think active defragmentation will buy you much over the long term at all)
- 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/
| |