[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOMdWSLjk8pZUgM6QHdeJ3C8Q-Y07GM4QuaSyAyP2jZcAMLOhA@mail.gmail.com>
Date: Thu, 22 Feb 2024 12:26:35 -0800
From: Allen <allen.lkml@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: jiangshanlai@...il.com, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCHSET wq/for-6.9,6.10] workqueue: Implement disable/enable_work()
Tejun,
> > Lai, would you mind reviewing patches 0001-00010? If you're okay, I'll apply
> > them to wq/for-6.9 and then post the v2 patchset with the rest of the
> > patches updated to reflect your reviews.
> >
>
> In addition to the above features, would it make sense to introduce a "count"
> variable in struct work_struct?(I am not an expert with workqueue
> internals). Or perhaps
> we could use the existing "data" variable.
>
> struct tasklet_struct has a variable count, which is referenced in
> several drivers, Ex:
>
> from drivers/gpu/drm/i915/i915_tasklet.h
> 28 static inline bool __tasklet_is_enabled(const struct tasklet_struct *t)
> 29 {
> 30 return !atomic_read(&t->count);
> 31 }
>
> Also, there are several helper functions that use the "state"
> variable, tasklet_lock() which calls tasklet_trylock().
> I was thinking of adding/introducing these helper functions. Do let me
> know if it makes sense.
Ignore my above question. I quite frankly had not read enough about workqueues
or did look into the code. I do understand more than what I did after
looking at the
sources.
I do understand the work bits, but I don't fully understand the
concept of colors
(work_color, flush_color). A swift overview of it would be highly appreciated.
Thanks.
--
- Allen
Powered by blists - more mailing lists