From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeff Liu <jeff.liu@oracle.com>
Subject: Re: [LSF/MM ATTEND] slab cache extension -- slab cache in fixed size
Date: Wed, 26 Feb 2014 15:04:54 +0800
Message-ID: <530D9216.8050808@oracle.com>
References: <52D662A4.1080502@oracle.com> <alpine.DEB.2.10.1401310941430.6849@nuc> <530C0F08.1040000@oracle.com> <alpine.DEB.2.10.1402251225280.30822@nuc>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
To: Christoph Lameter <cl@linux.com>
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <alpine.DEB.2.10.1402251225280.30822@nuc>
Sender: owner-linux-mm@kvack.org
List-Id: linux-fsdevel.vger.kernel.org


On 02/26 2014 02:26 AM, Christoph Lameter wrote:
> On Tue, 25 Feb 2014, Jeff Liu wrote:
> 
>> In this case, another thing I'm hesitating about whether to export the cache_limit
>> via /proc/slabinfo by extending its tunable fields -- the per-CPU slab cache limit
>> and batchcount, as thus will change the user space interface and slabtop(1) need to
>> be modified accordingly.
> 
> Can you move the code to handle /sys/kernel/slab into mm/slab_common.c and
> then make slab use that? (Maybe a bit of a tough call but that has to be
> done at some point).

Yes, so that we can enabled those debug functions for both slab and slub, thanks for
your direction. :)

> 
> Once you got a directly with settings per slab then its trivial to add
> another field.

Indeed, that would be convenient afterwards.


Thanks,
-Jeff

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>