Re: [RFC PATCH] mm/damon: remove damon_lock

[Alex Shi]

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