From: Jeff Liu <jeff.liu@oracle.com>
To: Christoph Lameter <cl@linux.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [LSF/MM ATTEND] slab cache extension -- slab cache in fixed size
Date: Tue, 25 Feb 2014 11:33:28 +0800 [thread overview]
Message-ID: <530C0F08.1040000@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1401310941430.6849@nuc>
Hi Christoph,
I'm so sorry for the too late response as I took a longer vacations.
On 01/31 2014 23:44 PM, Christoph Lameter wrote:
> On Wed, 15 Jan 2014, Jeff Liu wrote:
>
>> Now I have a rough/stupid idea to add an extension to the slab caches [2], that is
>> if the slab cache size is limited which could be determined in cache_grow(), the
>> shrinker would be triggered accordingly. I'd like to learn/know if there are any
>> suggestions and similar requirements in other subsystems.
>
> Hmmm.... Looks like you got the right point where to insert the code to
> check for the limit. But lets leave the cache creation API the way it is.
> Add a function to set the limit?
Good idea. Yeah, changing the existing API is suboptimal than adding a new one.
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.
Thank!
-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>
next prev parent reply other threads:[~2014-02-25 3:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 10:27 [LSF/MM ATTEND] slab cache extension -- slab cache in fixed size Jeff Liu
2014-01-31 15:44 ` Christoph Lameter
2014-02-25 3:33 ` Jeff Liu [this message]
2014-02-25 18:26 ` Christoph Lameter
2014-02-26 7:04 ` Jeff Liu
2014-02-26 15:02 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530C0F08.1040000@oracle.com \
--to=jeff.liu@oracle.com \
--cc=cl@linux.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.