From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752961Ab1LSMNA (ORCPT ); Mon, 19 Dec 2011 07:13:00 -0500 Received: from cantor2.suse.de ([195.135.220.15]:41118 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752751Ab1LSMM5 (ORCPT ); Mon, 19 Dec 2011 07:12:57 -0500 Date: Mon, 19 Dec 2011 13:12:55 +0100 From: Michal Hocko To: Anton Vorontsov Cc: KOSAKI Motohiro , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Rik van Riel , Pavel Machek , Greg Kroah-Hartman , Andrew Morton , David Rientjes , John Stultz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner , KAMEZAWA Hiroyuki Subject: Re: Android low memory killer vs. memory pressure notifications Message-ID: <20111219121255.GA2086@tiehlicka.suse.cz> References: <20111219025328.GA26249@oksana.dev.rtsoft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111219025328.GA26249@oksana.dev.rtsoft.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Didn't get to the patch yet but a comment on memcg] On Mon 19-12-11 06:53:28, Anton Vorontsov wrote: [...] > - Use memory controller cgroup (CGROUP_MEM_RES_CTLR) notifications from > the kernel side, plus userland "manager" that would kill applications. > > The main downside of this approach is that mem_cg needs 20 bytes per > page (on a 32 bit machine). So on a 32 bit machine with 4K pages > that's approx. 0.5% of RAM, or, in other words, 5MB on a 1GB machine. page_cgroup is 16B per page and with the current Johannes' memcg naturalization work (in the mmotm tree) we are down to 8B per page (we got rid of lru). Kamezawa has some patches to get rid of the flags so we will be down to 4B per page on 32b. Is this still too much? I would be really careful about a yet another lowmem notification mechanism. > 0.5% doesn't sound too bad, but 5MB does, quite a little bit. So, > mem_cg feels like an overkill for this simple task (see the driver at > the very bottom). Why is it an overkill? I think that having 2 groups (active and inactive) and move tasks between then sounds quite elegant. You can implement an user space oom handler in both groups (active will just move a task to the inactive group which inactive will kill a task which hasn't been used for the longest time). -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic