On Sun, Jul 19, 2020 at 2:12 AM Alex Shi [off-list ref] wrote:

在 2020/7/18 下午10:15, Alex Shi 写道:

quoted

quoted

quoted

 struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb);

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 14c668b7e793..36c1680efd90 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h

@@ -261,6 +261,8 @@ struct lruvec {
        atomic_long_t                   nonresident_age;
        /* Refaults at the time of last reclaim cycle */
        unsigned long                   refaults;
+       /* per lruvec lru_lock for memcg */
+       spinlock_t                      lru_lock;
        /* Various lruvec state flags (enum lruvec_flags) */
        unsigned long                   flags;

Any reason for placing this here instead of at the end of the
structure? From what I can tell it looks like lruvec is already 128B
long so placing the lock on the end would put it into the next
cacheline which may provide some performance benefit since it is
likely to be bounced quite a bit.

Rong Chen(Cced) once reported a performance regression when the lock at
the end of struct, and move here could remove it.
Although I can't not reproduce. But I trust his report.

Oops, Rong's report is on another member which is different with current
struct.

Compare to move to tail, how about to move it to head of struct, which is
close to lru list? Did you have some data of the place change?

I don't have specific data, just anecdotal evidence from the past that
usually you want to keep locks away from read-mostly items since they
cause obvious cache thrash. My concern was more with the other fields
in the structure such as pgdat since it should be a static value and
having it evicted would likely be more expensive than just leaving the
cacheline as it is.

Why not just wrap the entire thing in a check for "lruvec"? Yes you
could theoretically be modding with a value of 0, but it avoids a
secondary unnecessary check and branching.