[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150824074714.GA20106@gmail.com>
Date: Mon, 24 Aug 2015 09:47:14 +0200
From: Ingo Molnar <mingo@...nel.org>
To: George Spelvin <linux@...izon.com>
Cc: dave@...1.net, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux@...musvillemoes.dk, peterz@...radead.org, riel@...hat.com,
rientjes@...gle.com, torvalds@...ux-foundation.org
Subject: Re: [PATCH 3/3 v4] mm/vmalloc: Cache the vmalloc memory info
* Ingo Molnar <mingo@...nel.org> wrote:
> +/*
> + * Return a consistent snapshot of the current vmalloc allocation
> + * statistics, for /proc/meminfo:
> + */
> +void get_vmalloc_info(struct vmalloc_info *vmi)
> +{
> + int gen = READ_ONCE(vmap_info_gen);
> +
> + /*
> + * If the generation counter of the cache matches that of
> + * the vmalloc generation counter then return the cache:
> + */
> + if (READ_ONCE(vmap_info_cache_gen) == gen) {
> + int gen_after;
> +
> + /*
> + * The two read barriers make sure that we read
> + * 'gen', 'vmap_info_cache' and 'gen_after' in
> + * precisely that order:
> + */
> + smp_rmb();
> + *vmi = vmap_info_cache;
> +
> + smp_rmb();
> + gen_after = READ_ONCE(vmap_info_gen);
> +
> + /* The cache is still valid: */
> + if (gen == gen_after)
> + return;
> +
> + /* Ok, the cache got invalidated just now, regenerate it */
> + gen = gen_after;
> + }
One more detail: I just realized that with the read barriers, the READ_ONCE()
accesses are not needed anymore - the barriers and the control dependencies are
enough.
This will further simplify the code.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists