From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/7] cache: prevent expansion races
Date: Tue, 30 Oct 2018 10:39:01 -0700 [thread overview]
Message-ID: <20181030173901.GI4135@magnolia> (raw)
In-Reply-To: <20181030112043.6034-4-david@fromorbit.com>
On Tue, Oct 30, 2018 at 10:20:39PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> When a sudden buffer cache growth demand occurs from multiple
> concurrent sources, they can all fail shaking the cache at the same
> time and expand the cache. This results in the cache doubling in
> size multiple times when only a single expansion was really
> necessary. The resultant massive cache can cause repair to OOM as
> the cache will grow to much larger than memory can actually hold.
>
> Prevent this sudden and unnecessary expansion by rate limiting cache
> growth to one size increase every tens seconds. This is sufficient
> to prevent racing expansion calls from doing the wrong thing, but
> not too long to prevent necesary cache growth when it is undersized.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
> include/cache.h | 1 +
> libxfs/cache.c | 17 ++++++++++++++---
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/include/cache.h b/include/cache.h
> index 552b92489e46..1b774619f7a0 100644
> --- a/include/cache.h
> +++ b/include/cache.h
> @@ -114,6 +114,7 @@ struct cache {
> unsigned long long c_misses; /* cache misses */
> unsigned long long c_hits; /* cache hits */
> unsigned int c_max; /* max nodes ever used */
> + time_t expand_time; /* time of last expansion */
> };
>
> struct cache *cache_init(int, unsigned int, struct cache_operations *);
> diff --git a/libxfs/cache.c b/libxfs/cache.c
> index 139c7c1b9e71..e10df395e60e 100644
> --- a/libxfs/cache.c
> +++ b/libxfs/cache.c
> @@ -62,6 +62,7 @@ cache_init(
> cache->bulkrelse = cache_operations->bulkrelse ?
> cache_operations->bulkrelse : cache_generic_bulkrelse;
> pthread_mutex_init(&cache->c_mutex, NULL);
> + time(&cache->expand_time);
>
> for (i = 0; i < hashsize; i++) {
> list_head_init(&cache->c_hash[i].ch_list);
> @@ -77,15 +78,25 @@ cache_init(
> return cache;
> }
>
> +/*
> + * rate limit expansion so several concurrent shakes don't instantly all
> + * expand the cache multiple times and blow repair to OOM death.
> + */
> static void
> cache_expand(
> - struct cache * cache)
> + struct cache *cache)
> {
> + time_t now;
> +
> pthread_mutex_lock(&cache->c_mutex);
> + time(&now);
> + if (now - cache->expand_time > 10) {
At first I wondered to myself about what happens if we fill the cache
fast enough that we run out of space in less than ten seconds, but
(afaict) the cache_expand caller will keep trying shake/expand until it
gets something, right?
--D
> #ifdef CACHE_DEBUG
> - fprintf(stderr, "doubling cache size to %d\n", 2 * cache->c_maxcount);
> + fprintf(stderr, "doubling cache size to %d\n", 2 * cache->c_maxcount);
> #endif
> - cache->c_maxcount *= 2;
> + cache->c_maxcount *= 2;
> + cache->expand_time = now;
> + }
> pthread_mutex_unlock(&cache->c_mutex);
> }
>
> --
> 2.19.1
>
next prev parent reply other threads:[~2018-10-31 2:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-30 11:20 [PATCH 0/7] xfs_repair: scale to 150,000 iops Dave Chinner
2018-10-30 11:20 ` [PATCH 1/7] Revert "xfs_repair: treat zero da btree pointers as corruption" Dave Chinner
2018-10-30 17:20 ` Darrick J. Wong
2018-10-30 19:35 ` Eric Sandeen
2018-10-30 20:11 ` Dave Chinner
2018-10-30 11:20 ` [PATCH 2/7] repair: don't dirty inodes which are not unlinked Dave Chinner
2018-10-30 17:26 ` Darrick J. Wong
2018-10-30 20:03 ` Eric Sandeen
2018-10-30 20:09 ` Eric Sandeen
2018-10-30 20:34 ` Dave Chinner
2018-10-30 20:40 ` Eric Sandeen
2018-10-30 20:58 ` Dave Chinner
2018-10-30 11:20 ` [PATCH 3/7] cache: prevent expansion races Dave Chinner
2018-10-30 17:39 ` Darrick J. Wong [this message]
2018-10-30 20:35 ` Dave Chinner
2018-10-31 17:13 ` Brian Foster
2018-11-01 1:27 ` Dave Chinner
2018-11-01 13:17 ` Brian Foster
2018-11-01 21:23 ` Dave Chinner
2018-11-02 11:31 ` Brian Foster
2018-11-02 23:26 ` Dave Chinner
2018-10-30 11:20 ` [PATCH 4/7] workqueue: bound maximum queue depth Dave Chinner
2018-10-30 17:58 ` Darrick J. Wong
2018-10-30 20:53 ` Dave Chinner
2018-10-31 17:14 ` Brian Foster
2018-10-30 11:20 ` [PATCH 5/7] repair: Protect bad inode list with mutex Dave Chinner
2018-10-30 17:44 ` Darrick J. Wong
2018-10-30 20:54 ` Dave Chinner
2018-10-30 11:20 ` [PATCH 6/7] repair: protect inode chunk tree records with a mutex Dave Chinner
2018-10-30 17:46 ` Darrick J. Wong
2018-10-30 11:20 ` [PATCH 7/7] repair: parallelise phase 6 Dave Chinner
2018-10-30 17:51 ` Darrick J. Wong
2018-10-30 20:55 ` Dave Chinner
2018-11-07 5:44 ` [PATCH 0/7] xfs_repair: scale to 150,000 iops Arkadiusz Miśkiewicz
2018-11-07 6:48 ` Dave Chinner
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=20181030173901.GI4135@magnolia \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).