From: Marcelo <marcelo.tosatti@cyclades.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Marcelo <marcelo.tosatti@cyclades.com>,
linux-mm@kvack.org, akpm@osdl.org, dgc@sgi.com,
dipankar@in.ibm.com, mbligh@mbligh.org, manfred@colorfullife.com
Subject: Re: [PATCH] per-page SLAB freeing (only dcache for now)
Date: Sat, 1 Oct 2005 18:52:54 -0300 [thread overview]
Message-ID: <20051001215254.GA19736@xeon.cnet> (raw)
In-Reply-To: <Pine.LNX.4.62.0509301934390.31011@schroedinger.engr.sgi.com>
On Fri, Sep 30, 2005 at 07:46:31PM -0700, Christoph Lameter wrote:
> On Fri, 30 Sep 2005, Marcelo wrote:
>
> > I don't see any fundamental problems with this approach, are there any?
> > I'll clean it up and proceed to write the inode cache equivalent
> > if there aren't.
>
> Hmm. I think this needs to be some generic functionality in the slab
> allocator. If the allocator determines that the number of entries in a
> page become reasonably low then call a special function provided at
> slab creation time to try to free up the leftover entries.
>
> Something like
>
> int slab_try_free(void *);
>
> ?
>
> return true/false depending on success of attempt to free the entry.
I thought about having a mini-API for this such as "struct slab_reclaim_ops"
implemented by each reclaimable cache, invoked by a generic SLAB function.
Problem is that locking involved into looking at the SLAB elements is
cache specific (eg dcache_lock for the dcache, inode_lock for the icache,
and so on), so making a generic function seems pretty tricky, ie. you
need cache specific information in the generic function which is not so
easily "generifiable", if there's such a word.
> This method may also be useful to attempt to migrate slab pages to
> different nodes. If such a method is available then one can try to free
> all entries in a page relying on their recreation on another node if they
> are needed again.
Yep, haven't thought of that before, but it might be interesting to have
NUMA migration of cache elements.
Additionaly one can try to migrate recently referenced elements, instead
of freeing them, moving them to some partially used SLAB free slot
(Martin suggested that on IRC).
--
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:[~2005-10-01 21:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-30 19:37 Marcelo
2005-10-01 2:46 ` Christoph Lameter
2005-10-01 21:52 ` Marcelo [this message]
2005-10-03 15:24 ` Christoph Lameter
2005-10-03 20:37 ` Manfred Spraul
2005-10-03 22:17 ` Marcelo Tosatti
2005-10-04 17:04 ` Manfred Spraul
2005-10-06 16:01 ` Marcelo Tosatti
2005-10-22 1:30 ` Marcelo Tosatti
2005-10-22 6:31 ` Andrew Morton
2005-10-22 9:21 ` Arjan van de Ven
2005-10-22 17:08 ` Christoph Lameter
2005-10-22 17:13 ` ia64 page size (was Re: [PATCH] per-page SLAB freeing (only dcache for now)) Arjan van de Ven
2005-10-22 18:16 ` [PATCH] per-page SLAB freeing (only dcache for now) Manfred Spraul
2005-10-23 18:41 ` Marcelo Tosatti
2005-10-23 16:30 ` Marcelo Tosatti
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=20051001215254.GA19736@xeon.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=dgc@sgi.com \
--cc=dipankar@in.ibm.com \
--cc=linux-mm@kvack.org \
--cc=manfred@colorfullife.com \
--cc=mbligh@mbligh.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox