From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: [RFC][PATCH 0/13] Per-container dcache management (and a bit more) Date: Tue, 03 May 2011 16:14:37 +0400 Message-ID: <4DBFF1AD.90303@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel To: Hugh Dickins , Nick Piggin , Andrea Arcangeli , Rik van Riel , Dave Hansen , Alexa Return-path: Received: from mailhub.sw.ru ([195.214.232.25]:35224 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751419Ab1ECMOz (ORCPT ); Tue, 3 May 2011 08:14:55 -0400 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi. According to the "release early, release often" strategy :) I'm glad to propose this scratch implementation of what I was talking about at the LSF - the way to limit the dcache grow for both containerized and not systems (the set applies to 2.6.38). The first 5 patches are preparations for this, descriptive (I hope) comments are inside them. The general idea of this set is -- make the dentries subtrees be limited in size and shrink them as they hit the configured limit. Why subtrees? Because this lets having the [dentry -> group] reference without the reference count, letting the [dentry -> parent] one handle this. Why limited? For containers the answer is simple -- a container should not be allowed to consume too much of the host memory. For non-containerized systems the answer is -- to protect the kernel from the non-privileged attacks on the dcache memory like the "while :; do mkdir x; cd x; done" one and similar. What isn't in this patch yet, but should be done after the discussion * API. I haven't managed to invent any perfect solution, and would really like to have it discussed. In order to be able to play with it the ioctls + proc for listing are proposed. * New mounts management. Right now if you mount some new FS to a dentry which belongs to some managed set (I named it "mob" in this patchset), the new mount is managed with the system settings. This is not OK, the new mount should be managed with the settings of the mountpoint's mob. * Elegant shrink_dcache_memory on global memory shortage. By now the code walks the mobs and shinks some equal amount of dentries from them. Better shrinking policy can and probably should be implemented. Signed-off-by: Pavel Emelyanov