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
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
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
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/[email protected]
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
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
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/[email protected]
>
> 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