On Wed, Nov 10, 2021 at 10:35 PM SeongJae Park <sj@xxxxxxxxxx> wrote: > Yes, it would effectively avoid the problem case. However, I'm unsure how much > performance gain this change is providing, as apparently the lock is not being > used in performance critical parts. > > I'm also unsure if this change is reducing the complexity of the code or not. > For an example, this change allows someone to show non-zero nr_running_ctxs > while no real kdamond is running, before __damon_start() is called, or when it > failed. I think this would never be a real issue, but might make my poor brain > a little bit confused when debugging. > > Also, we might add some more variables and code section that should be mutually > exclusive to concurrent DAMON users in future. > > atomic_t is obviously enough for protecting a variable. But, IMHO, it might > not necessarily be the best choice for non-performance-critical mutex sections. > > Please feel free to let me know if I'm missing something. > hi SJ, Thanks for the quick reply! Yes, it's fine to use mutex on a slow path, it won't cost much. but I just feel itchy while looking at the code, especially since it only guards an int... Anyway, it's up to you. Thanks Alex
