Re: [PATCH 0/4] mm/memcg: Address PREEMPT_RT problems instead of disabling it.

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2022-01-25 15:21:46 [-0800], Andrew Morton wrote:
> On Tue, 25 Jan 2022 17:43:33 +0100 Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> > Hi,
> > 
> > this series is a follow up to the initial RFC
> >     https://lore.kernel.org/all/20211222114111.2206248-1-bigeasy@linutronix.de
> > 
> > and aims to enable MEMCG for PREEMPT_RT instead of disabling it.
> > 
> > where it has been suggested that I should try again with memcg instead
> > of simply disabling it.
> > 
> > Changes since the RFC:
> > - cgroup.event_control / memory.soft_limit_in_bytes is disabled on
> >   PREEMPT_RT. It is a deprecated v1 feature. Fixing the signal path is
> >   not worth it.
> > 
> > - The updates to per-CPU counters are usually synchronised by disabling
> >   interrupts. There are a few spots where assumption about disabled
> >   interrupts are not true on PREEMPT_RT and therefore preemption is
> >   disabled. This is okay since the counter are never written from
> >   in_irq() context.
> > 
> > Patch #2 deals with the counters.
> > 
> > Patch #3 is a follow up to
> >    https://lkml.kernel.org/r/20211214144412.447035-1-longman@redhat.com
> > 
> > Patch #4 restricts the task_obj usage to !PREEMPTION kernels. Based on
> > the numbers in 
> >    https://lore.kernel.org/all/YdX+INO9gQje6d0S@linutronix.de
> 
> This isn't a terribly useful [0/n], sorry.  It would be better to have
> something self-contained which doesn't require that the reader chase
> down increasingly old links and figure out what changed during
> successive iterations.

I'm sorry. I didn't want to copy the numbers and make the impression of
doing the numbers now on -rc1.
 
> > I tested them on CONFIG_PREEMPT_NONE + CONFIG_PREEMPT_RT with the
> > tools/testing/selftests/cgroup/* tests. It looked good except for the
> > following (which was also there before the patches):
> > - test_kmem sometimes complained about:
> >  not ok 2 test_kmem_memcg_deletion
> 
> Is this a new issue?

No, I saw it already on 5.16.0-rc5.

> Does this happen with these patches when CONFIG_PREEMPT_RT=n?

Yes. The problem reported by the test is independent of the series and
RT.

> > - test_memcontrol complained always about
> >  not ok 3 test_memcg_min
> >  not ok 4 test_memcg_low
> >  and did not finish.
> 
> Similarly, is this caused by these patches?  Is it only triggered under
> preempt_rt?

No. This happens regardless of these patches and RT.

> > - lockdep complains were triggered by test_core and test_freezer (both
> >   had to run):
> 
> Ditto.

Also happens regardless of these patches and RT. It does not happen
always so sometimes I had to run test_core and test_freezer a few times
until lockdep complained.

Sebastian