On Fri, 6 Oct 2023, Dennis Zhou wrote: > > Sorry for the late chime in. I'm traveling right now. No problem at all, thanks for looking. > > I haven't been super happy lately with percpu_counter as it has had a > few corner cases such as the cpu_dying_mask fiasco which I thought we > fixed with a series from tglx [1]. If not I can resurrect it and pull > it. > > I feel like percpu_counter is deviating from its original intended > usecase which, from my perspective, was a thin wrapper around a percpu > variable. At this point we seem to be bolting onto percpu_counter > instead of giving it a clear focus for what it's supposed to do well. > I think I understand the use case, and ultimately it's kind of the > duality where I think it was xfs is using percpu_counters where it must > be > 0 for the value to make sense and there was a race condition with > cpu dying [2]. > > At this point, I think it's probably better to wholy think about the > lower bound and upper bound problem of percpu_counter wrt the # of > online cpus. > > Thanks, > Dennis > > [1] https://lore.kernel.org/lkml/20230414162755.281993820@xxxxxxxxxxxxx/ > [2] https://lore.kernel.org/lkml/20230406015629.1804722-1-yebin@xxxxxxxxxxxxxxx/ Thanks for the links. I can see that the current cpu_dying situation is not ideal, but don't see any need to get any deeper into that for percpu_counter_limited_add(): I did consider an update to remove its use of cpu_dying_mask, but that just seemed wrong - it should do the same as is currently done in __percpu_counter_sum(), then be updated along with that when cpu_dying is sorted, by tglx's series or otherwise. I don't think I agree with you about percpu_counter deviating from its original intended usecase; but I haven't studied the history to see what that initial usecase was. Whatever, we've had percpu_counter_add() and percpu_counter_compare() for many years, and percpu_counter_limited_add() is just an atomic combination of those: I don't see it as deviating at all. Hugh
