On Tue, 11 Sep 2007, Nick Piggin wrote: > There is a limitation in the VM. Fragmentation. You keep saying this > is a solved issue and just assuming you'll be able to fix any cases > that come up as they happen. > > I still don't get the feeling you realise that there is a fundamental > fragmentation issue that is unsolvable with Mel's approach. Well my problem first of all is that you did not read the full message. It discusses that later and provides page pools to address the issue. Secondly you keep FUDding people with lots of theoretical concerns assuming Mel's approaches must fail. If there is an issue (I guess there must be right?) then please give us a concrete case of a failure that we can work against. > The idea that there even _is_ a bug to fail when higher order pages > cannot be allocated was also brushed aside by some people at the > vm/fs summit. I don't know if those people had gone through the > math about this, but it goes somewhat like this: if you use a 64K > page size, you can "run out of memory" with 93% of your pages free. > If you use a 2MB page size, you can fail with 99.8% of your pages > still free. That's 64GB of memory used on a 32TB Altix. Allocations can currently fail and all code has the requirement to handle failure cases in one form or another. Currently we can only handle up to order 3 allocs it seems. 2M pages (and in particular pagesizes > MAX_ORDER) will have to be handled by a separate large page pool facility discussed in the earlier message. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
