From: Andreas Gruenbacher <agruen@suse.de>
To: Andreas Dilger <adilger@dilger.ca>
Cc: "linux-ext4" <linux-ext4@vger.kernel.org>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] mbcache: Remove unused features
Date: Thu, 22 Jul 2010 02:07:40 +0200 [thread overview]
Message-ID: <201007220207.40940.agruen@suse.de> (raw)
In-Reply-To: <4F3D0C4D-BA6B-490E-B656-774578B3F67B@dilger.ca>
>From https://bugzilla.lustre.org/show_bug.cgi?id=22771#c24 :
> On our production system, the hash table contain 64 entries (6 bits) for a
> cache of 2307267 entries.
> A count in each list give a good load balance : number of entries vary
> between 35782 to 36496 while the optimal repartition is 2307267 / 64 =
> 36051.
Hehe, I like that sense of humor :)
On Thursday 22 July 2010 01:18:39 Andreas Dilger wrote:
> Is it possible to allow mbcache to be disabled, either for the whole
> kernel, on a per-filesystem basis, or adaptively if the cache hit rate is
> very low (any of these is fine, not all of them).
We could do that, but making the cache not degrade so badly would be a good
idea in any case. The number of buckets is currently fixed for ext[234] so it
would make sense to either make that number dynamic or limit the maximum
number of cache entries. The latter will probably be good enough for most
workloads.
> Attached is a patch that allows manually disabling mbcache on a
> per-filesystem basis with a mount option.
> I don't think fixing the mbcache to be more efficient (more buckets, more
> locks, etc) is really solving the problem which is that mbcache is adding
> overhead without value in these situations.
A mount option would be very ugly, but a kernel internal NO_MBCACHE flag
sounds more acceptable to me.
> Better would be to
> automatically disable it if e.g. some hundreds or thousands of objects
> were inserted into the cache and there was < 1% cache hit rate.
This assumes that the workload won't change.
> That would help everyone, even those people who don't know they have a
> problem.
People who don't know they have a problem would also be helped by making the
cache not degrade so badly, right?
Even better would be to use a more appropriate inode size, but you've pointed
that out in the bug already.
Thanks,
Andreas
next prev parent reply other threads:[~2010-07-22 0:07 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-18 1:01 [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > Wang Sheng-Hui
2010-07-18 1:01 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Wang Sheng-Hui
2010-07-18 1:01 ` Wang Sheng-Hui
2010-07-18 4:06 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan Eric Sandeen
2010-07-18 4:06 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Eric Sandeen
2010-07-18 4:06 ` Eric Sandeen
2010-07-18 6:01 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan Christoph Hellwig
2010-07-18 6:01 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Christoph Hellwig
2010-07-18 6:36 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan Wang Sheng-Hui
2010-07-18 6:36 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Wang Sheng-Hui
2010-07-18 6:36 ` Wang Sheng-Hui
2010-07-19 18:39 ` Andreas Gruenbacher
2010-07-19 18:39 ` Andreas Gruenbacher
2010-07-20 1:02 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > shenghui
2010-07-20 1:02 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 shenghui
2010-07-20 1:04 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > shenghui
2010-07-20 1:04 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 shenghui
2010-07-20 1:04 ` shenghui
2010-07-20 15:13 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan Eric Sandeen
2010-07-20 15:13 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Eric Sandeen
2010-07-20 16:34 ` Andreas Gruenbacher
2010-07-20 16:34 ` Andreas Gruenbacher
2010-07-20 16:34 ` Andreas Gruenbacher
2010-07-19 18:40 ` Andreas Gruenbacher
2010-07-19 18:40 ` Andreas Gruenbacher
2010-07-21 10:53 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > Wang Sheng-Hui
2010-07-21 10:53 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Wang Sheng-Hui
2010-07-21 10:53 ` Wang Sheng-Hui
2010-07-21 10:53 ` Wang Sheng-Hui
2010-07-21 14:00 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan Eric Sandeen
2010-07-21 14:00 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Eric Sandeen
2010-07-21 14:00 ` Eric Sandeen
2010-07-19 16:19 ` [PATCH 1/2] mbcache: Remove unused features Andreas Gruenbacher
2010-07-19 16:19 ` Andreas Gruenbacher
2010-07-19 16:19 ` Andreas Gruenbacher
2010-07-21 23:18 ` Andreas Dilger
2010-07-22 0:07 ` Andreas Gruenbacher [this message]
2010-07-21 17:44 ` [PATCH 2/2] mbcache: fix shrinker function return value Andreas Gruenbacher
2010-07-21 17:44 ` Andreas Gruenbacher
2010-07-21 17:44 ` Andreas Gruenbacher
2010-07-21 17:57 ` [PATCH 0/2] mbcache fixes Andreas Gruenbacher
2010-07-21 17:57 ` Andreas Gruenbacher
2010-07-21 17:57 ` Andreas Gruenbacher
2010-07-21 23:22 ` Al Viro
2010-07-21 23:22 ` Al Viro
2010-07-21 23:22 ` Al Viro
2010-07-22 0:54 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan Wang Sheng-Hui
2010-07-22 0:54 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 Wang Sheng-Hui
2010-07-22 0:54 ` Wang Sheng-Hui
2010-07-22 0:54 ` Wang Sheng-Hui
2010-07-22 1:06 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > shenghui
2010-07-22 1:06 ` [PATCH] fix return value for mb_cache_shrink_fn when nr_to_scan > 0 shenghui
2010-07-22 1:06 ` shenghui
2010-07-22 1:06 ` shenghui
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=201007220207.40940.agruen@suse.de \
--to=agruen@suse.de \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.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.