* George Spelvin wrote:
> 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.
Ha! :-) Fixed.
> vmap_info_gen should be initialized to 1 to force an initial
> cache update.
Yeah.
> Second, I don't see wh
John Stoffel wrote:
>> vmap_info_gen should be initialized to 1 to force an initial
>> cache update.
> Blech, it should be initialized with a proper #define
> VMAP_CACHE_NEEDS_UPDATE 1, instead of more magic numbers.
Er... this is a joke, right?
First, this number is used exactly once, and it's
George> John Stoffel wrote:
>>> vmap_info_gen should be initialized to 1 to force an initial
>>> cache update.
>> Blech, it should be initialized with a proper #define
>> VMAP_CACHE_NEEDS_UPDATE 1, instead of more magic numbers.
George> Er... this is a joke, right?
Not really. The comment mad
* Ingo Molnar 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 t
> "Ingo" == Ingo Molnar writes:
Ingo> * George Spelvin wrote:
>> 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.
Ingo> Ha! :-) Fixed.
>> vmap_info_gen should be initialized to 1 to force an init
5 matches
Mail list logo