linux-kernel - Re: [RFC][PATCH] memcg soft limit (yet another new design) v1

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]

Message-Id: <20090331085729.c0c2b384.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Tue, 31 Mar 2009 08:57:29 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"kosaki.motohiro@...fujitsu.com" <kosaki.motohiro@...fujitsu.com>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>
Subject: Re: [RFC][PATCH] memcg soft limit (yet another new design) v1

On Sun, 29 Mar 2009 18:31:38 +0530
Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:

> > 
> >  - Inactive/Active rotation scheme of global LRU will be broken.
> > 
> >  - File/Anon reclaim ratio scheme of global LRU will be broken.
> >     - vm.swappiness will be ignored.
> > 
> 
> Not true, with my patches none of these are affected since the reclaim
> for soft limits is limited to mem cgroup LRU lists only. Zone reclaim
> that happens in parallel can of-course change the global LRU.
> 
> >  - If using memcg's memory reclaim routine, 
> >     - shrink_slab() will be never called.
> >     - stale SwapCache has no chance to be reclaimed (stale SwapCache means
> >       readed but not used one.)
> >     - memcg can have no memory in a zone.
> >     - memcg can have no Anon memory
> >     - lumpty_reclaim() is not called.
> > 
> > 
> > This patch tries to avoid to use existing memcg's reclaim routine and
> > just tell "Hints" to global LRU. This patch is briefly tested and shows
> > good result to me. (But may not to you. plz brame me.)
> > 
> 
> I don't like the results, they are functionaly broken (see my other
> email). Why should "B" get reclaimed from if it is not above its soft
> limit? Why is there a swapout from "B"?
> 
I explained in other mail.




> 
> > Major characteristic is.
> >  - memcg will be inserted to softlimit-queue at charge() if usage excess
> >    soft limit.
> >  - softlimit-queue is a queue with priority. priority is detemined by size
> >    of excessing usage.
> >  - memcg's soft limit hooks is called by shrink_xxx_list() to show hints.
> >  - Behavior is affected by vm.swappiness and LRU scan rate is determined by
> >    global LRU's status.
> > 
> > I'm sorry that I'm tend not to tell enough explanation.  plz ask me.
> > There will be much discussion points, anyway. As usual, I'm not in hurry.
> >
> 
> The code seems to add a lot of complexity and does not achieve expected
> functionality. I am going to start testing this series soon
>  



> > 
> > ==brief test result==
> > On 2CPU/1.6GB bytes machine. create group A and B
> >   A.  soft limit=300M
> >   B.  no soft limit
> > 
> >   Run a malloc() program on B and allcoate 1G of memory. The program just
> >   sleeps after allocating memory and no memory refernce after it.
> >   Run make -j 6 and compile the kernel.
> > 
> >   When vm.swappiness = 60  => 60MB of memory are swapped out from B.
> >   When vm.swappiness = 10  => 1MB of memory are swapped out from B    
> > 
> >   If no soft limit, 350MB of swap out will happen from B.(swapiness=60)
> > 
> > I'll try much more complexed ones in the weekend.
> 
> Please see my response to this test result in a previous email.
> 
you too, I repoted to your thread one week ago,

Thanks,
-Kame

> -- 
> 	Balbir

--
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/