On Tue, Aug 25, 2015 at 9:39 AM, Linus Torvalds
wrote:
>
> I'm not convinced anybody actually uses those values, and they are
> getting *less* relevant rather than more (on 64-bit, those values
> really don't matter, since the vmalloc space isn't really a
> limitation)
Side note: the people who a
On Sun, Aug 23, 2015 at 2:56 PM, Rasmus Villemoes
wrote:
>
> [Maybe one could just remove the fields and see if anybody actually
> notices/cares any longer. Or, if they are only used by kernel
> developers, put them in their own file.]
I'm actually inclined to try exactly that for 4.3, and then t
On Sun, Aug 23, 2015 at 10:17:51AM +0200, Ingo Molnar wrote:
> +static u64 vmap_info_gen;
> +static u64 vmap_info_cache_gen;
> +void get_vmalloc_info(struct vmalloc_info *vmi)
> +{
> + u64 gen = READ_ONCE(vmap_info_gen);
> +
> + /*
> + * If the generation counter of the cache matches
On Mon, Aug 24 2015, Ingo Molnar wrote:
>
> Thanks, is the fixed up changelog below better?
>
Yes, though Linus specifically referred to "make test" (but I guess one
could/should consider that part of the build process).
Rasmus
> mm/vmalloc: Cache the vmalloc memory info
>
> Linus reported th
* Rasmus Villemoes wrote:
> I was curious why these fields were ever added to /proc/meminfo, and dug
> up this:
>
> commit d262ee3ee6ba4f5f6125571d93d9d63191d2ef76
> Author: Andrew Morton
> Date: Sat Apr 12 12:59:04 2003 -0700
>
> [PATCH] vmalloc stats in /proc/meminfo
>
> From
* Rasmus Villemoes wrote:
> On Sun, Aug 23 2015, Ingo Molnar wrote:
>
> > Ok, fair enough - so how about the attached approach instead, which
> > uses a 64-bit generation counter to track changes to the vmalloc
> > state.
>
> How does this invalidation approach compare to the jiffies approach
First, an actual, albeit minor, bug: initializing both vmap_info_gen
and vmap_info_cache_gen to 0 marks the cache as valid, which it's not.
vmap_info_gen should be initialized to 1 to force an initial
cache update.
Second, I don't see why you need a 64-bit counter. Seqlocks consider
32 bits (31
I was curious why these fields were ever added to /proc/meminfo, and dug
up this:
commit d262ee3ee6ba4f5f6125571d93d9d63191d2ef76
Author: Andrew Morton
Date: Sat Apr 12 12:59:04 2003 -0700
[PATCH] vmalloc stats in /proc/meminfo
From: Matt Porter
There was a thread a whil
On Sun, Aug 23 2015, Ingo Molnar wrote:
> Ok, fair enough - so how about the attached approach instead, which
> uses a 64-bit generation counter to track changes to the vmalloc
> state.
How does this invalidation approach compare to the jiffies approach? In
other words, how often does the vmallo
9 matches
Mail list logo
