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. > 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? -- Michal Hocko SUSE Labs
