Re: RE: [PATCH 4.4 4.9 v1 2/2] mm: slub: allocate_slab() enables IRQ right after scheduler starts

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

On 2025-02-10 07:20:35 [+0000], kazuhiro3.hayashi@toshiba.co.jp wrote:
> Hello,
Hi,

> The question here is whether to insert SYSTEM_SCHEDULING is acceptable
> or not in LTS phase. This addition would change behavior of future fixes
> or out-of-tree codes that check system_state, so adjustments similar to
> the mainline series[2] (2/17 ~ 15/17) are needed for them.
> 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.

What questions can you ask?
- Do you backport code that relies on `system_states' or did so in the
  past?
- Is more likely to backport code from before v4.13 or after? Either way
  you need to look at this.

> Best regards,
> Kazu

Sebastian