From: Christoph Lameter <cl@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: penberg@cs.helsinki.fi, nickpiggin@yahoo.com.au,
hugh@veritas.com, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: SLUB defrag pull request?
Date: Mon, 20 Oct 2008 14:53:40 -0500 [thread overview]
Message-ID: <48FCE1C4.20807@linux-foundation.org> (raw)
In-Reply-To: <E1Ks0QX-0002aC-SQ@pomaz-ex.szeredi.hu>
Miklos Szeredi wrote:
> So, isn't it possible to do without get_dentries()? What's the
> fundamental difference between this and regular cache shrinking?
The fundamental difference is that slab defrag operates on sparsely populated
dentries. It comes into effect when the density of dentries per page is low
and lots of memory is wasted. It defragments by kicking out dentries in low
density pages. These can then be reclaimed.
> Case below was brainfart, please ignore. But that doesn't really
> help: the VFS assumes that you cannot umount while there are busy
> dentries/inodes. Usually it works this way: VFS first gets vfsmount
> ref, then gets dentry ref, and releases them in the opposite order.
> And umount is not allowed if vfsmount has a non-zero refcount (it's a
> bit more complicated, but the essense is the same).
The dentries that we get a ref on are candidates for removal. Their lifetime
is limited. Unmounting while we are trying to remove dentries/inodes results
in two mechanisms removing dentries/inodes.
If we have obtained a reference then invalidate_list() will return the number
of busy inodes which would trigger the printk in generic_shutdown_super(). But
these are inodes currently being reclaimed by slab defrag. Just waiting a bit
would remedy the situation.
We would need some way to make generic_shutdown_super() wait until slab defrag
is finished.
--
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:[~2008-10-20 19:53 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1223883004.31587.15.camel@penberg-laptop>
[not found] ` <1223883164.31587.16.camel@penberg-laptop>
[not found] ` <Pine.LNX.4.64.0810131227120.20511@blonde.site>
2008-10-13 12:54 ` Nick Piggin
2008-10-13 13:59 ` Miklos Szeredi
2008-10-13 14:27 ` Miklos Szeredi
2008-10-13 16:35 ` Christoph Lameter
2008-10-13 14:49 ` Miklos Szeredi
2008-10-13 15:22 ` Miklos Szeredi
2008-10-20 14:59 ` Christoph Lameter
2008-10-20 18:01 ` Miklos Szeredi
2008-10-20 18:22 ` Christoph Lameter
2008-10-20 18:40 ` Miklos Szeredi
2008-10-20 19:11 ` Christoph Lameter
2008-10-20 19:28 ` Miklos Szeredi
2008-10-20 19:53 ` Christoph Lameter [this message]
2008-10-20 20:50 ` Miklos Szeredi
2008-10-21 23:17 ` Christoph Lameter
2008-10-22 7:10 ` Miklos Szeredi
2008-10-22 15:42 ` Christoph Lameter
2008-10-22 19:46 ` Miklos Szeredi
2008-10-22 19:54 ` Christoph Lameter
2008-10-22 20:11 ` Miklos Szeredi
2008-10-22 20:19 ` Christoph Lameter
2008-10-22 20:26 ` Miklos Szeredi
2008-10-22 20:48 ` Pekka Enberg
2008-10-22 21:01 ` Christoph Lameter
2008-10-22 21:04 ` Miklos Szeredi
2008-10-22 21:12 ` Pekka Enberg
2008-10-22 21:28 ` Christoph Lameter
2008-10-22 22:10 ` Miklos Szeredi
2008-10-22 23:20 ` Christoph Lameter
2008-10-23 7:10 ` Pekka Enberg
2008-10-23 8:38 ` Miklos Szeredi
2008-10-23 13:40 ` Christoph Lameter
2008-10-23 13:58 ` Pekka Enberg
2008-10-23 14:09 ` Christoph Lameter
2008-10-23 14:14 ` Pekka Enberg
2008-10-23 14:25 ` Christoph Lameter
2008-10-23 15:17 ` Eric Dumazet
2008-10-23 15:39 ` Christoph Lameter
2008-10-23 16:35 ` Eric Dumazet
2008-10-23 16:47 ` Christoph Lameter
2008-10-23 17:14 ` Eric Dumazet
2008-10-28 11:06 ` Pekka Enberg
2008-10-28 11:19 ` Nick Piggin
2008-10-30 15:45 ` Christoph Lameter
2008-10-22 20:59 ` Christoph Lameter
2008-10-20 23:04 ` Dave Chinner
2008-10-13 16:24 ` Christoph Lameter
2008-10-13 14:28 ` Miklos Szeredi
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=48FCE1C4.20807@linux-foundation.org \
--to=cl@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=penberg@cs.helsinki.fi \
/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