linux-kernel - Re: Scheduler bug related to rq->skip_clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Dec 2010 10:40:26 -0500 (EST)
From:	"Bjoern B. Brandenburg" <bbb.lst@...il.com>
To:	Mike Galbraith <efault@....de>
cc:	Yong Zhang <yong.zhang0@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrea Bastoni <bastoni@...g.uniroma2.it>,
	"James H. Anderson" <anderson@...unc.edu>,
	linux-kernel@...r.kernel.org
Subject: Re: Scheduler bug related to rq->skip_clock_update?



On Mon, 6 Dec 2010, Mike Galbraith wrote:

> On Sun, 2010-12-05 at 13:28 +0800, Yong Zhang wrote:
>
> > when we init idle task, we doesn't mark it on_rq.
> > My test show the concern is smoothed by below patch.
>
> Close :)
>
> The skip_clock_update flag should only be set if rq->curr is on_rq,
> because it it _that_ clock update during dequeue, and subsequent
> microscopic vruntime update it causes that we're trying to avoid.
>
> I think the below fixes it up properly.
>
> Sched: fix skip_clock_update optimization

Mike, Yong,

thanks for looking into this. On the x86_64 host, I'm now see seeing
delays of less than 0.1ms, which seems fine. On the ARM host, I'm seeing
delays of up to ~2.5ms. However, this only happens on CPU0, which makes me
think that it is probably just a byproduct of interrupts.

bbb@...trict10:~$ egrep 'cpu#|skip' /proc/sched_debug
cpu#0
  .skip_clock_count              : 98494
  .skip_clock_recent_max         : 2543000
  .skip_clock_max                : 9876875
cpu#1
  .skip_clock_count              : 61084
  .skip_clock_recent_max         : 861750
  .skip_clock_max                : 1382875
cpu#2
  .skip_clock_count              : 60846
  .skip_clock_recent_max         : 193375
  .skip_clock_max                : 2236500
cpu#3
  .skip_clock_count              : 60270
  .skip_clock_recent_max         : 318750
  .skip_clock_max                : 1679000
bbb@...trict10:~$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 33:         29          0          0          0         GIC  timer
 35:         49          0          0          0         GIC  isp1760-hcd:usb1
 36:        145          0          0          0         GIC  uart-pl011
 39:         10          0          0          0         GIC  kmi-pl050
 40:        116          0          0          0         GIC  kmi-pl050
 41:     215789          0          0          0         GIC  eth0
 46:          0          0          0          0         GIC  mmci-pl18x (cmd)
 47:          0          0          0          0         GIC  mmci-pl18x (pio)
IPI:     102721     103079      94532     111227
LOC:     115129     114840     114166     115122
Err:          0

So the latest patch seems to solve the issue.

Tested-by: Bjoern B. Brandenburg <bbb.lst@...il.com>

Btw, I think this patch is a good candidate for the .36-stable tree since
it fixes a major regression.

Thanks,
Bjoern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/