From: Andrew Morton <akpm@linux-foundation.org>
To: "Jan Beulich" <JBeulich@suse.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] consolidate WARN_...ONCE() static variables
Date: Tue, 28 Feb 2012 00:12:10 -0800 [thread overview]
Message-ID: <20120228001210.26b59479.akpm@linux-foundation.org> (raw)
In-Reply-To: <4F4C983002000078000751AE@nat28.tlf.novell.com>
On Tue, 28 Feb 2012 08:02:40 +0000 "Jan Beulich" <JBeulich@suse.com> wrote:
> >>> On 28.02.12 at 08:44, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Tue, 28 Feb 2012 07:41:54 +0000 "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> >> >>> On 28.02.12 at 01:03, Andrew Morton <akpm@linux-foundation.org> wrote:
> >> > On Mon, 27 Feb 2012 15:10:34 +0000
> >> > "Jan Beulich" <JBeulich@suse.com> wrote:
> >> >
> >> >> Due to the alignment of following variables, these typically consume
> >> >> more than just the single byte that 'bool' requires, and as there are
> >> >> a few hundred instances, the cache pollution (not so much the waste of
> >> >> memory) sums up. Put these variables into their own section, outside
> >> >> of any half way frequently used memory range.
> >> >>
> >> >> v2: Do the same also to the __warned variable of rcu_lockdep_assert().
> >> >> (Don't, however, include the ones used by printk_once() and alike, as
> >> >> they can potentially be hot.)
> >> >
> >> > I have a bad feeling that I still don't understand this patch. Ho hum.
> >> >
> >> > What are the rules for the new .data.unlikely section? When should
> >> > people put variables into this section? Perhaps we can document this
> >> > somewhere?
> >>
> >> If I knew the "where" part of this, I could put together a few sentences.
> >> I just grep-ed through Documentation/, without finding e.g. any rules
> >> or guidelines for using {,un}likely()...
> >>
> >
> > At the definition site in vmlinux.lds?
>
> Sorry, Andrew, but this makes no sense to me.
I really don't care - anywhere you like. Just the darn changelog, if
nowhere else.
I still don't have an answer to my question :( Some statement
describing what the new section is *for*. Seems a pretty important
thing?
next prev parent reply other threads:[~2012-02-28 8:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-27 15:10 [PATCH v2] consolidate WARN_...ONCE() static variables Jan Beulich
2012-02-28 0:03 ` Andrew Morton
2012-02-28 7:41 ` Jan Beulich
2012-02-28 7:44 ` Andrew Morton
2012-02-28 8:02 ` Jan Beulich
2012-02-28 8:12 ` Andrew Morton [this message]
2012-02-28 8:16 ` Jan Beulich
2012-02-28 8:32 ` Andrew Morton
2012-02-28 8:58 ` Jan Beulich
2012-02-28 21:19 ` Andrew Morton
2012-02-29 8:21 ` Jan Beulich
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=20120228001210.26b59479.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=JBeulich@suse.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.