On Tue, Apr 16, 2019 at 10:43 AM Borislav Petkov <b...@alien8.de> wrote: > > On Tue, Apr 16, 2019 at 10:09:49AM -0700, Cong Wang wrote: > > They are just locks requiring different contexts, I don't see how one is > > simpler than the other. Do you mind to be more specific? > > Yes, I'd like for this whole CEC code to be lazy and preemptible as it > is not at all important when it does its work, as long as it gets it > done eventually. > > Can't be preemptible with spinlocks.
Got it, but the work done with holding a spinlock isn't heavy, given there are only at most 512 elements in the array. > > > By workqueue, you must mean to say delayed work, right? > > > > But the global workqueue is not serialized either, > > Serialized with what? Insertions? Hmm? We still have to serialize either the timer callback or a delayed work with the rest of array updates (add or delete), right? As far as I understand, two works in the global workqueue could be still ran in parallel on different CPU's, this is why I said it has to be an ordered queue to guarantee the serialization. > > That's what the mutex is for and the insertions happen in process > context. > > So yeah, delayed_work sounds like what it should do. I.e., > queue_delayed_work() and decay_interval_set() should do > mod_delayed_work(). Something along those lines, anyways. This part is perfectly understood. Thanks.
