[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9AE4F1FC-2B6A-4EB4-8626-9936B8EB5CBB@gmail.com>
Date: Mon, 07 May 2018 20:23:09 -0700
From: Joel Fernandes <joel.opensrc@...il.com>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>, tglx@...utronix.de,
arnd@...db.de, cl@...ux.com
CC: keescook@...omium.org, luto@...capital.net, longman@...hat.com,
viro@...iv.linux.org.uk, willy@...radead.org,
ebiederm@...ssion.com, linux-arch@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: expland documentation over __read_mostly
On May 7, 2018 4:15:06 PM PDT, "Luis R. Rodriguez" <mcgrof@...nel.org> wrote:
>__read_mostly can easily be misused by folks, its not meant for
>just read-only data. There are performance reasons for using it, but
>we also don't provide any guidance about its use. Provide a bit more
>guidance over it use.
>
>Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
>---
> include/linux/cache.h | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>Every now and then we get a patch suggesting to use __read_mostly for
>something new or old but with no justifications. Add a bit more
>verbiage to help guide its users.
>
>Is this sufficient documentation to at least ask for a reason in the
>commit
>log as to why its being used for new entries? Or should we be explicit
>and
>ask for such justifications in commit logs? Taken from prior
>discussions
>with Christoph Lameter [0] over its use.
>
>[0]
>https://lkml.kernel.org/r/alpine.DEB.2.11.1504301343190.28879@gentwo.org
>
>diff --git a/include/linux/cache.h b/include/linux/cache.h
>index 750621e41d1c..62bc5adc0ed5 100644
>--- a/include/linux/cache.h
>+++ b/include/linux/cache.h
>@@ -15,8 +15,14 @@
>
> /*
>* __read_mostly is used to keep rarely changing variables out of
>frequently
>- * updated cachelines. If an architecture doesn't support it, ignore
>the
>- * hint.
>+ * updated cachelines. Its use should be reserved for data that is
>used
>+ * frequently in hot paths. Performance traces can help decide when to
>use
>+ * this. You want __read_mostly data to be tightly packed, so that in
>the
>+ * best case multiple frequently read variables for a hot path will be
>next
>+ * to each other in order to reduce the number of cachelines needed to
>+ * execute a critial path. We should be mindful and selective if its
Nit: in its use.
- Joel
>use.
>+ *
>+ * If an architecture doesn't support it, ignore the hint.
> */
> #ifndef __read_mostly
> #define __read_mostly
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists