From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753001Ab1HOMNd (ORCPT ); Mon, 15 Aug 2011 08:13:33 -0400 Received: from mailhub.sw.ru ([195.214.232.25]:41142 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752827Ab1HOMNc (ORCPT ); Mon, 15 Aug 2011 08:13:32 -0400 Message-ID: <4E490D47.8050105@parallels.com> Date: Mon, 15 Aug 2011 16:12:55 +0400 From: Pavel Emelyanov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pekka Enberg CC: Dave Chinner , Glauber Costa , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "containers@lists.linux-foundation.org" , Al Viro , Hugh Dickins , Nick Piggin , Andrea Arcangeli , Rik van Riel , Dave Hansen , James Bottomley , Eric Dumazet , Christoph Lameter , David Rientjes Subject: Re: [PATCH v3 3/4] limit nr_dentries per superblock References: <1313334832-1150-1-git-send-email-glommer@parallels.com> <1313334832-1150-4-git-send-email-glommer@parallels.com> <20110815104656.GG26978@dastard> <4E48FD8A.90401@parallels.com> <4E4903C1.9050207@parallels.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/15/2011 03:55 PM, Pekka Enberg wrote: > On Mon, Aug 15, 2011 at 2:32 PM, Pavel Emelyanov wrote: >>> Couldn't you simply do per-container "struct kmem_accounted_cache" in struct superblock? >> >> If by this you mean "account for all the kmem associated with particular superblock" then >> this is OK for us, but this can't be done in a simple >> >> if (used + size > limit) >> return -ENOMEM >> else { >> used += size; >> return 0; >> } >> >> manner, since once we hit the limit we should shrink the unused dentries. And most of the >> patches are about this. > > So you want to shrink dentries that were allocated in the container > that hit the dcache limit? How does this patch set deal with that? Or > are you referring to some other patches? Yes, this patchset does only the API part. The full idea is implemented (with poor API though) here: http://lwn.net/Articles/441164/ > Pekka > . > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH v3 3/4] limit nr_dentries per superblock Date: Mon, 15 Aug 2011 16:12:55 +0400 Message-ID: <4E490D47.8050105@parallels.com> References: <1313334832-1150-1-git-send-email-glommer@parallels.com> <1313334832-1150-4-git-send-email-glommer@parallels.com> <20110815104656.GG26978@dastard> <4E48FD8A.90401@parallels.com> <4E4903C1.9050207@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dave Chinner , Glauber Costa , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "containers@lists.linux-foundation.org" , Al Viro , Hugh Dickins , Nick Piggin , Andrea Arcangeli , Rik van Riel , Dave Hansen , James Bottomley , Eric Dumazet , Christoph Lameter , David Rientjes To: Pekka Enberg Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 08/15/2011 03:55 PM, Pekka Enberg wrote: > On Mon, Aug 15, 2011 at 2:32 PM, Pavel Emelyanov wrote: >>> Couldn't you simply do per-container "struct kmem_accounted_cache" in struct superblock? >> >> If by this you mean "account for all the kmem associated with particular superblock" then >> this is OK for us, but this can't be done in a simple >> >> if (used + size > limit) >> return -ENOMEM >> else { >> used += size; >> return 0; >> } >> >> manner, since once we hit the limit we should shrink the unused dentries. And most of the >> patches are about this. > > So you want to shrink dentries that were allocated in the container > that hit the dcache limit? How does this patch set deal with that? Or > are you referring to some other patches? Yes, this patchset does only the API part. The full idea is implemented (with poor API though) here: http://lwn.net/Articles/441164/ > Pekka > . >