On Mon, Mar 3, 2025 at 7:11 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > But I don't like the "add separate full/empty fields that duplicate > things", just to have those written always under the lock, and then > loaded as one op. > > I think there are better models. > > So I think I'd prefer the "add the barrier" model. > I was trying to avoid having to reason about the fences, I would argue not having to worry about this makes future changes easier to make. > We could also possibly just make head/tail be 16-bit fields, and then > read things atomically by reading them as a single 32-bit word. That > would expose the (existing) alpha issues more, since alpha doesn't > have atomic 16-bit writes, but I can't find it in myself to care. I > guess we could make it be two aligned 32-bit fields on alpha, and just > use 64-bit reads. I admit I did not think of this, pretty obvious now that you mention it. Perhaps either Prateek or Swapnil would be interested in coding this up? Ultimately the crux of the issue is their finding. > > I just generally dislike redundant information in data structures. > Then you get into nasty cases where some path forgets to update the > redundant fields correctly. So I'd really just prefer the existing > model, just with being careful about this case. > The stock code already has a dedicated routine to advance the tail, adding one for head (instead of an ad-hoc increment) is borderline just clean up. Then having both recalc the state imo does not add any bug-pronness [I did ignore the CONFIG_WATCH_QUEUE case though] afaics. Even so, per the above, that's a side note. -- Mateusz Guzik <mjguzik gmail.com>
