lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 8 Feb 2012 20:34:14 +0800
From:	Hillf Danton <dhillf@...il.com>
To:	Johannes Stezenbach <js@...21.net>
Cc:	Toralf Förster <toralf.foerster@....de>,
	linux-kernel@...r.kernel.org, Rik van Riel <riel@...hat.com>,
	linux-mm@...ck.org
Subject: Re: swap storm since kernel 3.2.x

2012/2/8 Johannes Stezenbach <js@...21.net>:
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ