Re: swap storm since kernel 3.2.x

[Hillf Danton]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/