lkml.org 
[lkml]   [2018]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: write_lock_irq(&tasklist_lock)
Hi Prasad,

On Tue, May 22, 2018 at 12:40:05PM -0700, Sodagudi Prasad wrote:
> When following test is executed on 4.14.41 stable kernel, observed that one
> of the core is waiting for tasklist_lock for long time with IRQs disabled.
> ./stress-ng-64 --get 8 -t 3h --times --metrics-brief
>
> Every time when device is crashed, I observed that one the task stuck at
> fork system call and waiting for tasklist_lock as writer with irq disabled.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/fork.c?h=linux-4.14.y#n1843

Please use a newer kernel. We've addressed this in mainline by moving
arm64 over to the qrwlock implementation which (after some other changes)
guarantees forward progress for well-behaved readers and writers.

To give an example from locktorture with 2 writers and 8 readers, after
a few seconds I see:

rwlock:
Writes: Total: 6725 Max/Min: 0/0 Fail: 0
Reads: Total: 5103727 Max/Min: 0/0 Fail: 0

qrwlock:
Writes: Total: 155284 Max/Min: 0/0 Fail: 0
Reads: Total: 767703 Max/Min: 0/0 Fail: 0

so the ratio is closer to ~6:1 rather than ~191:1 for this case. The
total locking throughput has dropped, but that's expected for this type
of lock where maximum throughput would be achieved by favouring readers.

Will

\
 
 \ /
  Last update: 2018-05-23 15:06    [W:0.068 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site