On 12/23/21 02:34, Sebastian Andrzej Siewior wrote:
On 2021-12-22 21:31:36 [-0500], Waiman Long wrote:
On 12/22/21 06:41, Sebastian Andrzej Siewior wrote:
The per-CPU counter are modified with the non-atomic modifier. The
consistency is ensure by disabling interrupts for the update.
This breaks on PREEMPT_RT because some sections additionally
acquire a spinlock_t lock (which becomes sleeping and must not be
acquired with disabled interrupts). Another problem is that
mem_cgroup_swapout() expects to be invoked with disabled interrupts
because the caller has to acquire a spinlock_t which is acquired with
disabled interrupts. Since spinlock_t never disables interrupts on
PREEMPT_RT the interrupts are never disabled at this point.
The code is never called from in_irq() context on PREEMPT_RT therefore
How do you guarantee that these percpu update functions won't be called in
in_irq() context for PREEMPT_RT? Do you think we should add a
WARN_ON_ONCE(in_irq()) just to be sure?
There are no invocations to the memory allocator (neither malloc() nor
free()) on RT and the memory allocator itself (SLUB and the
page-allocator so both) has sleeping locks. That means invocations
in_atomic() are bad. All interrupt handler are force-threaded. Those
which are not (like timer, per-CPU interrupts or those which explicitly
asked not to be force threaded) are limited in their doing as they can't
invoke anything that has a sleeping lock. Lockdep or
CONFIG_DEBUG_ATOMIC_SLEEP will yell here.
The other counter are protected the same way, see
c68ed7945701a ("mm/vmstat: protect per cpu variables with preempt disable on RT")
Thanks for the explanation as I am less familiar with other PREEMPT_RT
specific changes.
Cheers,
Longman
