在 2020/7/19 下午11:14, Alexander Duyck 写道: >> 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. > Thanks for comments, Alex. So, sounds like moving the lru_lock to head of struct lruvec could be better. >> - __mod_zone_page_state(zone, NR_MLOCK, delta_munlocked); >> + if (delta_munlocked) >> + __mod_zone_page_state(zone, NR_MLOCK, delta_munlocked); >> if (lruvec) >> unlock_page_lruvec_irq(lruvec); > 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. Right, and the delta_munlocked value could be checked inside the accounting func Thanks!
