lkml.org 
[lkml]   [2021]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH] mm/damon: remove damon_lock
On Wed, Nov 10, 2021 at 10:35 PM SeongJae Park <sj@kernel.org> 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

\
 
 \ /
  Last update: 2021-11-10 16:36    [W:0.187 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site