linux-kernel - Re: [RFC][PATCH 4/6] Flat hierarchical reclaim by ID

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: <3526.10.75.179.61.1228832912.squirrel@webmail-b.css.fujitsu.com>
Date:	Tue, 9 Dec 2008 23:28:32 +0900 (JST)
From:	"KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	"KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	"lizf@...fujitsu.com" <lizf@...fujitsu.com>,
	"menage@...gle.com" <menage@...gle.com>,
	"kosaki.motohiro@...fujitsu.com" <kosaki.motohiro@...fujitsu.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 4/6] Flat hierarchical reclaim by ID

Balbir Singh said:
> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> [2008-12-09
> 20:09:15]:
>
>>
>> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
>>
>> Implement hierarchy reclaim by cgroup_id.
>>
>> What changes:
>> 	- Page reclaim is not done by tree-walk algorithm
>> 	- mem_cgroup->last_schan_child is changed to be ID, not pointer.
>> 	- no cgroup_lock, done under RCU.
>> 	- scanning order is just defined by ID's order.
>> 	  (Scan by round-robin logic.)
>>
>> Changelog: v3 -> v4
>> 	- adjusted to changes in base kernel.
>> 	- is_acnestor() is moved to other patch.
>>
>> Changelog: v2 -> v3
>> 	- fixed use_hierarchy==0 case
>>
>> Changelog: v1 -> v2
>> 	- make use of css_tryget();
>> 	- count # of loops rather than remembering position.
>>
>> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujisu.com>
>
> I have not yet run the patch, but the heuristics seem a lot like
> magic. I am not against scanning by order, but is order the right way
> to scan groups?
My consideration is
  - Both of current your implementation and this round robin is just
    an example. I never think some kind of search algorighm detemined by
    shape of tree is the best way.
  - No one knows what order is the best, now. We have to find it.
  - The best order will be determined by some kind of calculation rather
    than shape of tree and must pass by tons of tests.
    This needs much amount of time and patient work. VM management is not
    so easy thing.
    I think your soft-limit idea can be easily merged onto this patch set.

> Does this order reflect their position in the hierarchy?
  No. just scan IDs from last scannned one in RR.
  BTW, can you show what an algorithm works well in following case ?
  ex)
    groupA/   limit=1G     usage=300M
          01/ limit=600M   usage=600M
          02/ limit=700M   usage=70M
          03/ limit=100M   usage=30M
   Which one should be shrinked at first and why ?
   1) when group_A hit limits.
   2) when group_A/01 hit limits.
   3) when group_A/02 hit limits.
   I can't now.

   This patch itself uses round-robin and have no special order.
   I think implenting good algorithm under this needs some amount of time.

> Shouldn't id's belong to cgroups instead of just memory controller?
If Paul rejects, I'll move this to memcg. But bio-cgroup people also use
ID and, in this summer, I posted swap-cgroup-ID patch and asked to
implement IDs under cgroup rather than subsys. (asked by Paul or you.)

>From implementation, hierarchy code management at el. should go into
cgroup.c and it gives us clear view rather than implemented under memcg.

-Kame
> I would push back ids to cgroups infrastructure.
>


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