On Wed, Jan 26, 2011 at 03:23:02PM +0000, Mel Gorman wrote: > On Wed, Jan 26, 2011 at 02:17:46PM +0000, Mel Gorman wrote: > > On Mon, Jan 24, 2011 at 04:00:34PM +0100, Andrea Arcangeli wrote: > > > eOn Mon, Jan 24, 2011 at 11:56:46AM +0800, Shaohua Li wrote: > > > > Hi, > > > > With transparent huge page, min_free_kbytes is set too big. > > > > Before: > > > > Node 0, zone DMA32 > > > > pages free 1812 > > > > min 1424 > > > > low 1780 > > > > high 2136 > > > > scanned 0 > > > > spanned 519168 > > > > present 511496 > > > > > > > > After: > > > > Node 0, zone DMA32 > > > > pages free 482708 > > > > min 11178 > > > > low 13972 > > > > high 16767 > > > > scanned 0 > > > > spanned 519168 > > > > present 511496 > > > > This caused different performance problems in our test. I wonder why we > > > > set the value so big. > > > > > > It's to enable Mel's anti-frag that keeps pageblocks with movable and > > > unmovable stuff separated, same as "hugeadm > > > --set-recommended-min_free_kbytes". > > > > > > Now that I checked, I'm seeing quite too much free memory with only 4G > > > of ram... You can see the difference with a "cp /dev/sda /dev/null" in > > > background interleaving these two commands: > > > > > > > What kernel is this and is commit > > [99504748: mm: kswapd: stop high-order balancing when any suitable zone > > is balanced] present in the kernel you are testing? > > > > I'm having very little luck reproducing your scenario with > > 2.6.38-rc2. > > Scratch that, a machine with 4G does reproduce it. The machine I was > trying was 2G. Will dig more. I can't reproduce on a 16G system (there I never get more than an hundred mbyte free even with cp in background, which is very fine for 16G). I only reproduce on my 4G workstation, and it happens also after echo never >enabled (so without THP). I was reproducing it with "cp" anyway which isn't triggering THP allocations but I verified to be sure. When I start cp kswapd wasn't running yet, so free levels go down to 170M, then kswapd starts and it frees 700M and then 700m remains free forever until I stop "cp". The high wmark are never set to more than 85M for the normal zone, which is not excessively horrible. I'd still like to lower the wmark though! (there are 2 pageblocks reserved in the min watermark for each type, why not just 1? removing that *2 would already halve it saving some 40M of ram!). But the wmarks don't seem the real offender, maybe it's something related to the tiny pci32 zone that materialize on 4g systems that relocate some little memory over 4g to make space for the pci32 mmio. I didn't yet finish to debug it. However in presence of memory pressure the low wmark is the limit not the high wmark (and when kswapd isn't running free levels already go down to 170M even where I can reproduce). Maybe the failure with too much memory free may be only because of the increased wmark from some 20M to ~100M, and maybe I'm seeing something unrelated to that problem. __GFP_NO_KSWAPD I exclude is the issue as it happens without THP too and there's just one place where huge_memory.c allocates memory. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>