Messages in this thread | | | Date | Fri, 22 Oct 2004 17:50:43 +0200 | From | Andrea Arcangeli <> | Subject | Re: ZONE_PADDING wastes 4 bytes of the new cacheline |
| |
On Thu, Oct 21, 2004 at 06:26:51PM -0700, Andrew Morton wrote: > But I'd be worried about making the default values anything other than zero > because nobody seems to be hitting the problems.
Google reported the bug two years ago, and that's when I've seen and fixed the problem the first time. Now the same workload that hurted two years ago would still hurt today on 2.6 (not on 2.4 anymore).
On a x86 32G box reserving 800M is needed, otherwise if you sawpoff I'll trivially deadlock the box, and if you implement relocationg you'd be wasting cpu. The only scare of a 32GB x86 owner, is to run out of lowmem. And the only scare of a 256G x86-64 or ia64 user is to run out of DMA. They cannot care less to spend 1/32 of HIGHMEM and 1/256 of HIGHMEM+NORMAL as an insurance to avoid expensive relocation memcopies in the middle of their peak loads and to avoid running out of memory.
I've some VM deadlocks in my queue, amittedly they should never deadlock but return -ENOMEM like 2.4 does, but that's an orthogonal known problem. I've also a DMA failure allocation in x86-64 that triggers the oom killer, that as well might not be strictly related, but there is no swap to relocate anonymous memory, there cannot be sawp since yast hasn't formatted the disk yet, my current workaround has been to turn off the oom killer during install, and that sort of worked for now despite somebody says it tends to slowdown.
I tried to tune the protection sysctl, but that resulted in too much memory being reserved and a deadlock with oom killer turned off, hence my decision to start fixing this instead of putting kernel internal knowledge on the pages_min algorithm to set protection properly (plus I wasn't 100% sure protection does exactly what the lowmem_reserve does, plus keeping both protecetion and pages_min is a waste of ram).
As for the sysctl, sure, I'm retaining those runtime settable improvements in 2.6, that's pretty cool compared to the not-working command line of 2.4 (such boot time command line is invoked far too late to make a difference but nobody has ever needed to turn off the values so nobody (or peraphs only one person) ever noticed ;).
> But then again, this get discussed so infrequently that by the time it > comes around again I've forgotten all the previous discussion. Ho hum.
;) - 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/
| |