From: "George Spelvin" <linux@horizon.com>
To: john@stoffel.org, mingo@kernel.org
Cc: dave@sr71.net, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux@horizon.com, linux@rasmusvillemoes.dk,
peterz@infradead.org, riel@redhat.com, rientjes@google.com,
torvalds@linux-foundation.org
Subject: Re: [PATCH 3/3 v4] mm/vmalloc: Cache the vmalloc memory info
Date: 24 Aug 2015 11:11:14 -0400 [thread overview]
Message-ID: <20150824151114.18743.qmail@ns.horizon.com> (raw)
In-Reply-To: <21979.6150.929309.800457@quad.stoffel.home>
John Stoffel <john@stoffel.org> 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 not part of a collection
of similar numbers. And the definition would be adjacent to the use.
We have easier ways of accomplishing that, called "comments".
Second, your proposed name is misleading. "needs update" is defined
as vmap_info_gen != vmap_info_cache_gen. There is no particular value
of either that has this meaning.
For example, initializing vmap_info_cache_gen to -1 would do just as well.
(I actually considered that before deciding that +1 was "simpler" than -1.)
For some versions of the code, an *arbitrary* difference is okay.
You could set one ot 0xDEADBEEF and the other to 0xFEEDFACE.
For other versions, the magnitude matters, but not *too* much.
Initializing it to 42 would be perfectly correct, but waste time doing
42 cache updates before settling down.
Singling out the value 1 as VMAP_CACHE_NEEDS_UPDATE is actively misleading.
> This will help keep bugs like this out in the future... I hope!
And this is the punchline, right?
The problem was not realizing that non-default initialization was required;
what we *call* the non-default value is irrelevant.
I doubt it would ever have been a real (i.e. noticeable) bug, actually;
the first bit of vmap activity in very early boot would have invalidated
the cache.
(John, my apologies if I went over the top and am contributing to LKML's
reputation for flaming. I *did* actually laugh, and *do* think it's a
dumb idea, but my annoyance is really directed at unpleasant memories of
mindless application of coding style guidelines. In this case, I suspect
you just posted before reading carefully enough to see the subtle logic.)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-08-24 15:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-23 4:48 [PATCH 0/3] mm/vmalloc: Cache the /proc/meminfo vmalloc statistics George Spelvin
2015-08-23 6:04 ` Ingo Molnar
2015-08-23 6:46 ` George Spelvin
2015-08-23 8:17 ` [PATCH 3/3 v3] mm/vmalloc: Cache the vmalloc memory info Ingo Molnar
2015-08-23 20:53 ` Rasmus Villemoes
2015-08-24 6:58 ` Ingo Molnar
2015-08-24 8:39 ` Rasmus Villemoes
2015-08-23 21:56 ` Rasmus Villemoes
2015-08-24 7:00 ` Ingo Molnar
2015-08-25 16:39 ` Linus Torvalds
2015-08-25 17:03 ` Linus Torvalds
2015-08-24 1:04 ` George Spelvin
2015-08-24 7:34 ` [PATCH 3/3 v4] " Ingo Molnar
2015-08-24 7:47 ` Ingo Molnar
2015-08-24 7:50 ` [PATCH 3/3 v5] " Ingo Molnar
2015-08-24 12:54 ` George Spelvin
2015-08-25 9:56 ` [PATCH 3/3 v6] " Ingo Molnar
2015-08-25 10:36 ` George Spelvin
2015-08-25 12:59 ` Peter Zijlstra
2015-08-25 14:19 ` Rasmus Villemoes
2015-08-25 15:11 ` George Spelvin
2015-08-24 13:11 ` [PATCH 3/3 v4] " John Stoffel
2015-08-24 15:11 ` George Spelvin [this message]
2015-08-24 15:55 ` John Stoffel
2015-08-25 12:46 ` [PATCH 3/3 v3] " Peter Zijlstra
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=20150824151114.18743.qmail@ns.horizon.com \
--to=linux@horizon.com \
--cc=dave@sr71.net \
--cc=john@stoffel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.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).