On 2022-01-13 15:48:03 [+0100], Michal Koutný wrote: > On Thu, Jan 13, 2022 at 02:08:10PM +0100, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > I added a preempt-disable() section restricted to RT to > > mem_cgroup_event_ratelimit(). > > Oh, I missed that one. > > (Than the decoupling of such mem_cgroup_event_ratelimit() also makes > some more sense.) > > That would mean that mem_cgroup_event_ratelimit() needs a > > local_irq_save(). If that is okay then sure I can move it that way. > > Whatever avoids the twisted code :-) Okay. So let me do that. > --- > > > I remember Michal (Hocko) suggested excluding/ rejecting soft limit but > > I didn't know where exactly and its implications. In this block here I > > just followed the replacement of irq-off with preempt-off for RT. > > Both soft limit and (these) event notifications are v1 features. Soft > limit itself is rather considered even misfeature. I guess the > implications would not be many since PREEMPT_RT+memcg users would be > new(?) so should rather start with v2 anyway. People often migrate to RT so they take whatever they have. In general I would like to keep RT & !RT in sync unless there are reasons to do it differently. > One way to disable it would be to reject writes into > memory.soft_limit_in_bytes or cgroup.event_control + documentation of > that. So avoiding these two also avoids memcg_check_events()? Right now it does not look like a big obstacle. It is the same pattern I'm following for the per-CPU RMW. If it is, I could avoid the writes and if0 the other function for RT. If I remove memcg_check_events() from the equation then we could keep the explicit irq-off regions (plus add a few). The only that would look odd then is that we disable interrupts for the RMW operation and preemption in other places (__count_memcg_events() invocations in swap.c and vmscan.c). Are there plans to remove v1 or is this part of "we must not break userland"? > Michal Sebastian
