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
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
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 Sun, Aug 23, 2015 at 2:56 PM, Rasmus Villemoes
li...@rasmusvillemoes.dk 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
On Tue, Aug 25, 2015 at 9:39 AM, Linus Torvalds
torva...@linux-foundation.org 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)
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 that of
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
* 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
>
>
* 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
* Rasmus Villemoes li...@rasmusvillemoes.dk wrote:
On Sun, Aug 23 2015, Ingo Molnar mi...@kernel.org 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
* Rasmus Villemoes li...@rasmusvillemoes.dk wrote:
I was curious why these fields were ever added to /proc/meminfo, and dug
up this:
commit d262ee3ee6ba4f5f6125571d93d9d63191d2ef76
Author: Andrew Morton a...@digeo.com
Date: Sat Apr 12 12:59:04 2003 -0700
[PATCH] vmalloc stats in
On Mon, Aug 24 2015, Ingo Molnar mi...@kernel.org 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
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
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
* George Spelvin wrote:
> Ingo Molnar wrote:
> > I think this is too complex.
> >
> > How about something simple like the patch below (on top of the third patch)?
>
> > It makes the vmalloc info transactional - /proc/meminfo will always print a
> > consistent set of numbers. (Not that we
* George Spelvin li...@horizon.com wrote:
Ingo Molnar mi...@kernel.org wrote:
I think this is too complex.
How about something simple like the patch below (on top of the third patch)?
It makes the vmalloc info transactional - /proc/meminfo will always print a
consistent set of
On Sun, Aug 23 2015, Ingo Molnar mi...@kernel.org 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
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 a...@digeo.com
Date: Sat Apr 12 12:59:04 2003 -0700
[PATCH] vmalloc stats in /proc/meminfo
From: Matt Porter por...@cox.net
20 matches
Mail list logo
