On 02/03/23 08:45, Michal Hocko wrote: > On Wed 01-03-23 18:23:19, Valentin Schneider wrote: >> On 26/02/22 21:41, Sebastian Andrzej Siewior wrote: >> > During the integration of PREEMPT_RT support, the code flow around >> > memcg_check_events() resulted in `twisted code'. Moving the code around >> > and avoiding then would then lead to an additional local-irq-save >> > section within memcg_check_events(). While looking better, it adds a >> > local-irq-save section to code flow which is usually within an >> > local-irq-off block on non-PREEMPT_RT configurations. >> > >> >> Hey, sorry for necro'ing a year-old thread - would you happen to remember >> what the issues were with memcg_check_events()? I ran tests against >> cgroupv1 using an eventfd on OOM with the usual debug arsenal and didn't >> detect anything, I'm guessing it has to do with the IRQ-off region >> memcg_check_events() is called from? > > I would have to look into details but IIRC the resulting code to make > the code RT safe was dreaded and hard to maintain as a result. As we > didn't really have any real life usecase, disabling the code was an > easier way to go forward. So it is not the code would be impossible to > be enabled for RT it just doeasn't seam to be worth all the complexity. > Right, thanks for having a look. >> I want cgroupv1 to die as much as the next person, but in that specific >> situation I kinda need cgroupv1 to behave somewhat sanely on RT with >> threshold events :/ > > Could you expand on the usecase? > In this case it's just some middleware leveraging memcontrol cgroups and setting up callbacks for in-cgroup OOM events. This is a supported feature in cgroupv2, so this isn't a problem of cgroupv1 vs cgroupv2 feature parity, but rather one of being in a transitional phase where the middleware itself hasn't fully migrated to using cgroupv2. > -- > Michal Hocko > SUSE Labs
