2012/2/8 Johannes Stezenbach <js@xxxxxxxxx>: > On Wed, Feb 08, 2012 at 09:56:15AM +0100, Toralf Förster wrote: >> >> From what I can tell is this: >> If the system is under heavy I/O load and hasn't too much free RAM (git pull, >> svn update and RAM consuming BOINC applications) then kernel 3.0.20 handle >> this somehow while 3.2.x run into a swap storm like. > > FWIW, I also saw heavy swapping with 3.2.2 with the > CONFIG_DEBUG_OBJECTS issue reported here: > http://lkml.org/lkml/2012/1/30/227 > > But the thing is that even though SUnreclaim was > huge there was still 1G MemFree and it swapped heavily > on idle system when just switching between e.g. Firefox and gvim. > > Today I'm running 3.2.4 with CONFIG_DEBUG_OBJECTS disabled > (but otherwise the same config) and it doesn't swap even > after a fair amount of I/O: Hah, looks not related to kswapd directly;) > > MemTotal: 3940088 kB > MemFree: 1024920 kB > Buffers: 293328 kB > Cached: 447796 kB > SwapCached: 24 kB > Active: 847136 kB > Inactive: 567200 kB > Active(anon): 478736 kB > Inactive(anon): 246744 kB > Active(file): 368400 kB > Inactive(file): 320456 kB > Unevictable: 0 kB > Mlocked: 0 kB > SwapTotal: 3903484 kB > SwapFree: 3903196 kB > Dirty: 16 kB > Writeback: 0 kB > AnonPages: 673192 kB > Mapped: 40956 kB > Shmem: 52268 kB > Slab: 1434188 kB > SReclaimable: 1367388 kB > SUnreclaim: 66800 kB > KernelStack: 1600 kB > PageTables: 4880 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 5873528 kB > Committed_AS: 1744916 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 348116 kB > VmallocChunk: 34359362739 kB > DirectMap4k: 12288 kB > DirectMap2M: 4098048 kB > > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > 586182 353006 60% 1.74K 32595 18 1043040K ext3_inode_cache > 289062 170979 59% 0.58K 10706 27 171296K dentry > 247266 107729 43% 0.42K 13737 18 109896K buffer_head > > And I want to ask kswapd to do less work, the attached diff is based on 3.2.5, mind to test it with CONFIG_DEBUG_OBJECTS enabled? Thanks Hillf --- a/mm/vmscan.c Wed Feb 8 20:10:14 2012 +++ b/mm/vmscan.c Wed Feb 8 20:15:22 2012 @@ -2113,8 +2113,11 @@ restart: * with multiple processes reclaiming pages, the total * freeing target can get unreasonably large. */ - if (nr_reclaimed >= nr_to_reclaim && priority < DEF_PRIORITY) + if (nr_reclaimed >= nr_to_reclaim) { + nr_to_reclaim = 0; break; + } + nr_to_reclaim -= nr_reclaimed; } blk_finish_plug(&plug); sc->nr_reclaimed += nr_reclaimed; @@ -2683,12 +2686,12 @@ static unsigned long balance_pgdat(pg_da * we want to put equal scanning pressure on each zone. */ .nr_to_reclaim = ULONG_MAX, - .order = order, .target_mem_cgroup = NULL, }; struct shrink_control shrink = { .gfp_mask = sc.gfp_mask, }; + sc.order = order = 0; loop_again: total_scanned = 0; sc.nr_reclaimed = 0; -- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href