Messages in this thread | | | Date | Tue, 25 May 2004 23:15:22 +0200 | From | Andrea Arcangeli <> | Subject | Re: 4g/4g for 2.6.6 |
| |
On Tue, May 25, 2004 at 04:10:29PM -0400, Rik van Riel wrote: > Fragmentation causes fork trouble (gone with the 4k stacks)
btw, the 4k stacks sounds not safe to me, most people only tested with 8k stacks so far, I wouldn't make that change in a production tree without an unstable cycle of testing in between. I'd rather risk a an allocation failure than a stack memory corruption.
x86-64 has per-irq stacks that allowed to reduce the stack size to 8k (which is very similar to 4k for an x86, but without per-irq stack it's too risky).
as for the dcache size, I can certainly imagine you can measure slowdown bigger than 4:4 in some very vfs intensive workload, but the stuff that needs 32G of ram normally uses only rawio or a few huge files as storage anyways. as for the kiobufs they're long gone in 2.6.
Possibly some webserving could use 32G as pure pagecache for the webserver with tons of tiny files, for such an app the 2:2 or 1:3 model should be better than 4:4. - 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/
| |