linux-kernel - Re: [patch 2/8] mm: memcg-aware global reclaim

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] [day] [month] [year] [list]

Message-ID: <CALWz4iw4ojn7GUJgWDV9wqGeXf-Oy0uDx0yJUhJpkuP5tffMwA@mail.gmail.com>
Date:	Mon, 29 Aug 2011 23:08:16 -0700
From:	Ying Han <yinghan@...gle.com>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Daisuke Nishimura <nishimura@....nes.nec.co.jp>,
	Michal Hocko <mhocko@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Minchan Kim <minchan.kim@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mel Gorman <mgorman@...e.de>, Greg Thelen <gthelen@...gle.com>,
	Michel Lespinasse <walken@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Hugh Dickins <hughd@...gle.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>
Subject: Re: [patch 2/8] mm: memcg-aware global reclaim

On Mon, Aug 29, 2011 at 12:57 AM, Johannes Weiner <hannes@...xchg.org> wrote:
>
> On Mon, Aug 29, 2011 at 12:22:02AM -0700, Ying Han wrote:
> > fix hierarchy_walk() to hold a reference to first mem_cgroup
> >
> > The first mem_cgroup returned from hierarchy_walk() is used to
> > terminate a round-trip. However there is no reference hold on
> > that which the first could be removed during the walking. The
> > patch including the following change:
> >
> > 1. hold a reference on the first mem_cgroup during the walk.
> > 2. rename the variable "root" to "target", which we found using
> > "root" is confusing in this content with root_mem_cgroup. better
> > naming is welcomed.
>
> Thanks for the report.
>
> This was actually not the only case that could lead to overlong (not
> necessarily endless) looping.
>
> With several scanning threads, a single thread may not encounter its
> first cgroup again for a long time, as the other threads would visit
> it.

Yes, that makes sense. And I think i found a issue on my patch which
it leaks reference count on the mem (first) which I can not do "rmdir"
after some memory pressure tests. So, please ignore the patch for now.

>
> I changed this to use scan generations.  Restarting the scan from id 0
> starts the next scan generation.  The iteration function returns NULL
> if the generation changed since a loop was started.
>
> This way, iterators can reliably detect whether they should call it
> quits without any requirements for previously encountered memcgs.

Ok, so if I have multiple threads hitting pressure under the same zone
and same memcg hierarchy tree, they all contribute to the single
iteration loop. And all the reclaimers will terminate if they together
made a full iteration under the hierarchy?

If so, i will look at your patch and no need for the fix i posted
early on. Meanwhile, I would be interested to look at some performance
data since the later one should save some cpu cycles going through
more memcgs than after the change.

Thanks

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