Hi, On 2026-01-14 10:26:07 +0800, Chao Li wrote: > So far I’ve only reviewed 0001 and 0002. I’m not very familiar with this > area, so the review has been a bit slow. > > Overall, 0001 looks good to me. It renames LW_FLAG_RELEASE_OK to > LW_FLAG_WAKE_IN_PROGRESS and inverts the meaning, which makes sense. I only > have a small nit on naming: the local variable “new_release_in_progress". I > see that it’s inherited from the old name and was updated from “_ok" to > “_in_progress", but now that the flag itself is renamed, would it make sense > to rename the variable as well? Something like “wake_in_progress" or > “new_wake_in_progress" might better reflect the new flag name.
Agreed that is better. Updated that way. > In 0002, a bunch of new macros are introduced. My initial impression wasn’t > great, mostly due to the amount of line wrapping. I think the previous formatting made it hard to actually write useful comments and caused line-length problems in the subsequent commits. Lines are cheap. > Looking a bit closer, I also noticed some duplication, for example, > "BUF_REFCOUNT_BITS + BUF_USAGECOUNT_BITS" appears more than once Yea, that's probably better to avoid. I'll add a fix to that in the commit changing it to 64bits, I think. > ; and a small inconsistency between BUF_STATE_GET_REFCOUNT and > BUF_STATE_GET_USAGECOUNT (even though the former doesn’t actually need a > shift). I don't see the point, if we later want to move refcounts elsewhere, we can do it at that time. > I tried a small refactor of the macro definitions in the attached diff to > see if things could be made a bit more regular. It introduces a helper macro > MASK() and a BUF_REFCOUNT_SHIFT constant, and removes a bit of > duplication. If you like it, feel free to take it; otherwise, please just > ignore it. Note that, the diff is based on 0002. I don't think the MASK thing is an improvement. > (I actually hesitated to attach a diff, because if you’ve already created a > CF entry, the attached diff could break the CI tests. If that happens, sorry > about that.) FWIW, there's a trick to avoid that: Rename your patch to end in .txt or such. Greetings, Andres Freund
