On May 7, 2018 4:15:06 PM PDT, "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> 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@xxxxxxxxxx> >--- > 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@xxxxxxxxxx > >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.
