Message-ID: 
 <TYCPR01MB11385606F5378CE8A0EACA29CE1FC2@TYCPR01MB11385.jpnprd01.prod.outlook.com>
Date: Wed, 12 Feb 2025 07:57:33 +0000
From: <kazuhiro3.hayashi@...hiba.co.jp>
To: <bigeasy@...utronix.de>
CC: <linux-kernel@...r.kernel.org>, <linux-rt-devel@...ts.linux.dev>,
        <cip-dev@...ts.cip-project.org>, <tglx@...utronix.de>,
        <rostedt@...dmis.org>, <linux-rt-users@...r.kernel.org>,
        <pavel@...x.de>
Subject: RE: RE: [PATCH 4.4 4.9 v1 2/2] mm: slub: allocate_slab() enables IRQ
 right after scheduler starts

Hi,

> > [...]
> > Can I ask if it's recommended to introduce SYSTEM_SCHEDULING even in LTS?
> > It's v4.4-rt specific topic but I think similar discussion is regularly
> > happening in newer -rt branches and LTS branches where PREEMPT_RT is merged.
> 
> In general I try to have the same code if it is easily possible. A few
> examples where this was not the case:
> - The printk code, as work is in progress, was never fully backported.
>   The changes between kernel versions were small and there was little to
>   none user visible changes. However changes under the hood were usually
>   big so in general it was not worth the effort.
> 
> - scheduling wise, we went from PREEMPT_LAZY to PREEMPT_AUTO to
>   LAZY_PREEMPT. Fixes within one implementation went all the way down
>   but the implementation as a whole was never backported. PREEMPT_AUTO
>   could be considered as half way done but nobody complained about
>   something in particular. It was "recently" discussed whether or not to
>   backport LAZY_PREEMPT to replace PREEMPT_AUTO in some of the lower
>   kernels but the changes required to backport it would be huge because
>   the scheduler in particular changed. So this is hard to justify.

Thank you for the examples!
In the both cases, it seems changes for backports are big and they affect
other backports which will happen in the future.
Comparing to those examples, I understood the SYSTEM_SCHEDULING case as
the one that backport should be considered and tried.

> What questions can you ask?

As it's clear that to backport the series[1] including SYSTEM_SCHEDULING
is preferred based on the interpretation above, I have no further query now.

> - Do you backport code that relies on `system_states' or did so in the
>   past?

I have not tried to backport code (1/17 & 17/17) that relies on
`system_scheduling` (custom variable) yet. No plan to do so anymore
as long as we can select to backport the series[1].

I have backported the full series[1] that relies on `SYSTEM_SCHEDULING`
(used as a value of `system_state` in upstream). It has been shared as [2].
CIP (4.4 RT) will decide if this backported series will be applied
based on all the feedbacks here.

> - Is more likely to backport code from before v4.13 or after? Either way
>   you need to look at this.

It's more likely to backport code from v4.13 that introduce the series[1].
The reason is IRQ controls in slub.c are changed significantly from v5.15-rt
and we concluded that it's hard to backport the changes into v4.4-rt[3].
Another mainline series[4] replaces most IRQ enable/disable codes in
slub.c with local_lock_irqsave() and local_unlock_irqrestore().
Eventually, `system_state` is no longer evaluated in SLAB functions at all
like the previous __slab_alloc().


Pavel,
Feel free to append information if you need.
Can we select the (revised) full backport[2] or anything else?
I'd like to know we are in the same page.

[1] https://lore.kernel.org/all/20170516184231.564888231@linutronix.de/T/
[2] https://lore.kernel.org/linux-rt-devel/1739170545-25011-1-git-send-email-kazuhiro3.hayashi@toshiba.co.jp/T/
[3] https://lore.kernel.org/all/TYCPR01MB11385C4C5CA765090E66944FFE1052@TYCPR01MB11385.jpnprd01.prod.outlook.com/
[4] https://lore.kernel.org/lkml/20210904105003.11688-1-vbabka@suse.cz/

Best regards,
Kazu

Powered by blists - more mailing lists