Hi, Christoph, David, Muchun and Hyeonggon
Thanks for your time.
Recently, I am also find other ways to solve this. That case was
provided by Muchun is useful (Thanks Muchun!). Indeed, it seems that use
n->list_lock here is unwise. Actually, I'm not sure if you recognize the
existence of such race? If all agrees this race, then the next question
may be: do we want to solve this problem? or as David said, it would be
better to deprecate validate attribute directly. I have no idea about
it, hope to rely on your experience.
In fact, I mainly want to collect your views on whether or how to fix
this bug here. Thanks!
Thanks again for your time:).
-wrw
On 6/2/22 11:14 PM, Christoph Lameter wrote:
On Mon, 30 May 2022, David Rientjes wrote:
Unconditionally taking n->list_lock will degrade performance.
This is a good point, it would be useful to gather some benchmarks for
workloads that are known to thrash some caches and would hit this path
such as netperf TCP_RR.
Its obvious that adding new spinlocks to some of the hottest functions in
the kernel will degrade performance. This goes against the basic design of
these functions to be as efficient as possible.
