On 2022-02-28 12:23:12 [+0100], Michal Hocko wrote: > On Mon 28-02-22 12:08:40, Sebastian Andrzej Siewior wrote: > > On 2022-02-28 09:05:45 [+0100], Michal Hocko wrote: > > > Acked-by: Michal Hocko <mhocko@xxxxxxxx> > > > > > > TBH I am not a fan of the counter special casing for the debugging > > > enabled warnings but I do not feel strong enough to push you trhough an > > > additional version round. > > > > do you want to get rid of the warnings completely? Since we had the > > check in memcg_stats_lock() it kinda felt useful to add something in > > __memcg_stats_lock() case, too. > > The thing that I dislike is that there is no other way for potential > users of those counters to know these expectations. This is not > documented anywhere so it mostly describes the _current_ state of the > code which might change in the future. We can be more thorough and > document counters wrt. to the context they can be used in which would > make this less of a concern of course. But this can be done on top hence > I do not want to push you for another versions. It is good to have your > current work merged in the next merge window as long as there are no > fallouts and for that it would be good to have it in the linux next and > exposed for some more testing rather than dealing with this deatails. Okay. Then I would suggest then I document the usage context of these counters once things settled down. Now there is no validation at all, so if someone uses the wrong context for a counter and you don't spot it during the review then there will be no warning at runtime. Sebastian
