On Mon, 4 Sept 2023 at 20:46, Andrey Konovalov <andreyknvl@xxxxxxxxx> wrote: > > On Wed, Aug 30, 2023 at 11:13 AM Marco Elver <elver@xxxxxxxxxx> wrote: > > > > > -static int new_pool_required = 1; > > > +static bool new_pool_required = true; > > > +/* Lock that protects the variables above. */ > > > +static DEFINE_RWLOCK(pool_rwlock); > > > > Despite this being a rwlock, it'll introduce tons of (cache) contention > > for the common case (stack depot entry exists). > > > > If creating new stack depot entries is only common during "warm-up" and > > then becomes exceedingly rare, I think a percpu-rwsem (read-lock is a > > CPU-local access, but write-locking is expensive) may be preferable. > > Good suggestion. I propose that we keep the rwlock for now, and I'll > check whether the performance is better with percpu-rwsem once I get > to implementing and testing the performance changes. I'll also check > whether percpu-rwsem makes sense for stack ring in tag-based KASAN > modes. I think it's quite obvious that the percpu-rwsem is better. A simple experiment is to measure the ratio of stackdepot hits vs misses. If the ratio is obviously skewed towards hits, then I'd just go with the percpu-rwsem. The performance benefit may not be measurable if you use a small system.
