On Tuesday 02 October 2007 06:50, Christoph Lameter wrote: > On Fri, 28 Sep 2007, Nick Piggin wrote: > > I thought it was slower. Have you fixed the performance regression? > > (OK, I read further down that you are still working on it but not > > confirmed yet...) > > The problem is with the weird way of Intel testing and communication. > Every 3-6 month or so they will tell you the system is X% up or down on > arch Y (and they wont give you details because its somehow secret). And > then there are conflicting statements by the two or so performance test > departments. One of them repeatedly assured me that they do not see any > regressions. Just so long as there aren't known regressions that would require higher order allocations to fix them. > > OK, so long as it isn't going to depend on using higher order pages, > > that's fine. (if they help even further as an optional thing, that's fine > > too. You can turn them on your huge systems and not even bother about > > adding this vmap fallback -- you won't have me to nag you about these > > purely theoretical issues). > > Well the vmap fallback is generally useful AFAICT. Higher order > allocations are common on some of our platforms. Order 1 failures even > affect essential things like stacks that have nothing to do with SLUB and > the LBS patchset. I don't know if it is worth the trouble, though. The best thing to do is to ensure that contiguous memory is not wasted on frivolous things... a few order-1 or 2 allocations aren't too much of a problem. The only high order allocation failure I've seen from fragmentation for a long time IIRC are the order-3 failures coming from e1000. And obviously they cannot use vmap. - 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
