[ANNOUNCE] v5.6.2-rt1

[ANNOUNCE] v5.6.2-rt1

[Sebastian Andrzej Siewior]

Dear RT folks!

I'm pleased to announce the v5.6.2-rt1 patch set. 

Changes since v5.4.28-rt19:

  - Rebase to v5.6.2

Known issues
     - It has been pointed out that due to changes to the printk code the
       internal buffer representation changed. This is only an issue if tools
       like `crash' are used to extract the printk buffer from a kernel memory
       image.

You can get this release via the git tree at:

    git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git v5.6.2-rt1

The RT patch against v5.6.2 can be found here:

    https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.6/older/patch-5.6.2-rt1.patch.xz

The split quilt queue is available at:

    https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.6/older/patches-5.6.2-rt1.tar.xz

Sebastian

0087-rcu-Use-a-raw_spinlock_t-for-kfree-batching.patch

[Mike Galbraith]

Hi Sebastian,

Just a heads up wrt $subject...

I had done the same in my 5.6 tree, but then 5.7 came along, and I had
to revisit due to 34c881745549e adding an allocation under that lock
with irqs disabled.  The same commit that added the lock added this.

	local_irq_save(flags);  // For safely calling this_cpu_ptr().

Whacking that instead of converting the lock cures 5.6 and 5.7 woes.

	-Mike

Re: 0087-rcu-Use-a-raw_spinlock_t-for-kfree-batching.patch

[Sebastian Andrzej Siewior]

On 2020-04-05 06:53:43 [+0200], Mike Galbraith wrote:
> Hi Sebastian,
Hi Mike,

> Just a heads up wrt $subject...
> 
> I had done the same in my 5.6 tree, but then 5.7 came along, and I had
> to revisit due to 34c881745549e adding an allocation under that lock
> with irqs disabled.  The same commit that added the lock added this.
> 
> 	local_irq_save(flags);  // For safely calling this_cpu_ptr().
> 
> Whacking that instead of converting the lock cures 5.6 and 5.7 woes.

So I think you are telling me that I made the lock raw and then they
added in v5.7 a __get_free_page() call in
kfree_call_rcu_add_ptr_to_bulk() which is invoked from the free path.

This is indeed not something that made me happy. Now let me think about
this for a moment…

> 	-Mike

Sebastian

Re: [ANNOUNCE] v5.6.2-rt1

[Juri Lelli]

Hi,

On 03/04/20 19:04, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
> 
> I'm pleased to announce the v5.6.2-rt1 patch set. 
> 
> Changes since v5.4.28-rt19:
> 
>   - Rebase to v5.6.2

I was reviewing the new set and I couldn't find v5.4.28-rt19
6dbbc833c99f ("mm: perform lru_add_drain_all() remotely"). Don't think
it has been squashed either.

Am I wrong? If not, why was that left out?

Thanks!

Juri

Re: [ANNOUNCE] v5.6.2-rt1

[Sebastian Andrzej Siewior]

On 2020-04-08 09:00:13 [+0200], Juri Lelli wrote:
> Hi,
Hi,

> On 03/04/20 19:04, Sebastian Andrzej Siewior wrote:
> > Dear RT folks!
> > 
> > I'm pleased to announce the v5.6.2-rt1 patch set. 
> > 
> > Changes since v5.4.28-rt19:
> > 
> >   - Rebase to v5.6.2
> 
> I was reviewing the new set and I couldn't find v5.4.28-rt19
> 6dbbc833c99f ("mm: perform lru_add_drain_all() remotely"). Don't think
> it has been squashed either.
> 
> Am I wrong? If not, why was that left out?

I was going to drop it from v5.4 but kept it last minute. I announced in
	https://lkml.kernel.org/r/20200309171350.kjb3pdjazhxm2li2@linutronix.de

that the problem it fixes is not limited to RT so we need a solution for
both config switches. The current plan for local-locks is not to work
cross CPU because it breaks the local_irq_save() / preempt_disable()
replacement which is something this patch relies on.
The worker triggered via vmstat_update() is also blocked if the user
task runs at an elevated priority for longer time.

> Thanks!
> 
> Juri

Sebastian

Re: [ANNOUNCE] v5.6.2-rt1

[Juri Lelli]

On 15/04/20 13:12, Sebastian Andrzej Siewior wrote:
> On 2020-04-08 09:00:13 [+0200], Juri Lelli wrote:
> > Hi,
> Hi,
> 
> > On 03/04/20 19:04, Sebastian Andrzej Siewior wrote:
> > > Dear RT folks!
> > > 
> > > I'm pleased to announce the v5.6.2-rt1 patch set. 
> > > 
> > > Changes since v5.4.28-rt19:
> > > 
> > >   - Rebase to v5.6.2
> > 
> > I was reviewing the new set and I couldn't find v5.4.28-rt19
> > 6dbbc833c99f ("mm: perform lru_add_drain_all() remotely"). Don't think
> > it has been squashed either.
> > 
> > Am I wrong? If not, why was that left out?
> 
> I was going to drop it from v5.4 but kept it last minute. I announced in
> 	https://lkml.kernel.org/r/20200309171350.kjb3pdjazhxm2li2@linutronix.de
> 
> that the problem it fixes is not limited to RT so we need a solution for
> both config switches. The current plan for local-locks is not to work
> cross CPU because it breaks the local_irq_save() / preempt_disable()
> replacement which is something this patch relies on.
> The worker triggered via vmstat_update() is also blocked if the user
> task runs at an elevated priority for longer time.

OK. Thanks for clarifying.

Best,

Juri