On Thu, Mar 30, 2023 at 12:06 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Wed 29-03-23 19:20:59, Shakeel Butt wrote: > > On Wed, Mar 29, 2023 at 11:41:39AM -0700, Yosry Ahmed wrote: > > > On Wed, Mar 29, 2023 at 4:22 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > > > On Tue 28-03-23 22:16:39, Yosry Ahmed wrote: > > > > > rstat flushing is too expensive to perform in irq context. > > > > > The previous patch removed the only context that may invoke an rstat > > > > > flush from irq context, add a WARN_ON_ONCE() to detect future > > > > > violations, or those that we are not aware of. > > > > > > > > > > Ideally, we wouldn't flush with irqs disabled either, but we have one > > > > > context today that does so in mem_cgroup_usage(). Forbid callers from > > > > > irq context for now, and hopefully we can also forbid callers with irqs > > > > > disabled in the future when we can get rid of this callsite. > > > > > > > > I am sorry to be late to the discussion. I wanted to follow up on > > > > Johannes reply in the previous version but you are too fast ;) > > > > > > > > I do agree that this looks rather arbitrary. You do not explain how the > > > > warning actually helps. Is the intention to be really verbose to the > > > > kernel log when somebody uses this interface from the IRQ context and > > > > get bug reports? What about configurations with panic on warn? Do we > > > > really want to crash their systems for something like that? > > > > > > Thanks for taking a look, Michal! > > > > > > The ultimate goal is not to flush in irq context or with irqs > > > disabled, as in some cases it causes irqs to be disabled for a long > > > time, as flushing is an expensive operation. The previous patch in the > > > series should have removed the only context that flushes in irq > > > context, and the purpose of the WARN_ON_ONCE() is to catch future uses > > > or uses that we might have missed. > > > > > > There is still one code path that flushes with irqs disabled (also > > > mem_cgroup_usage()), and we cannot remove this just yet; we need to > > > deprecate usage threshold events for root to do that. So we cannot > > > enforce not flushing with irqs disabled yet. > > > > > > So basically the patch is trying to enforce what we have now, not > > > flushing in irq context, and hopefully at some point we will also be > > > able to enforce not flushing with irqs disabled. > > > > > > If WARN_ON_ONCE() is the wrong tool for this, please let me know. > > > > > > > If I understand Michal's concern, the question is should be start with > > pr_warn_once() instead of WARN_ON_ONCE() and I think yes we should start > > with pr_warn_once(). > > Yes, I do not really like the WARN_ON here. It is an overkill. pr_warn > would much less intrusive but potentially incomplete because you won't > know who that offender is. So if you really care about those then you > would need to call dump_stack as well. > > So the real question is. Do we really care so deeply? After all somebody > might be calling this from within a spin lock or irq disabled section > resulting in a similar situation without noticing. There are discussions in [1] about making atomic rstat flush not disable irqs throughout the process, so in that case it would only result in a similar situation if the caller has irq disabled. The only caller that might have irq disabled is the same caller that might be in irq context before this series: mem_cgroup_usage(). On that note, and while I have your attention, I was wondering if we can eliminate the flush call completely from mem_cgroup_usage(), and read the global stats counters for root memcg instead of the root counters. There might be subtle differences, but the root memcg usage isn't super accurate now anyway (e.g. it doesn't include kernel memory). With that removed, no callers to rstat flushing would be from irq context or have irqs disabled. There will only be one atomic flusher (mem_cgroup_wb_stats()), and we can proceed with [1] if it causes a problem. What do you think? [1] https://lore.kernel.org/lkml/CAJD7tkZrp=4zWvjE9_010TAG1T_crCbf9P64UzJABspgcrGPKg@xxxxxxxxxxxxxx/ > -- > Michal Hocko > SUSE Labs
