linux-kernel - Definition of sched

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-next>] [day] [month] [year] [list]

Message-ID: <48D959E8.4000303@goop.org>
Date:	Tue, 23 Sep 2008 14:04:40 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Steven Rostedt <srostedt@...hat.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Definition of sched_clock broken

kernel/sched_clock.c has the comment:

 * The clock: sched_clock_cpu() is monotonic per cpu, and should be somewhat
 * consistent between cpus (never more than 2 jiffies difference).

The two jiffy restriction is way too restrictive.

Historically sched_clock() is intended to measure the amount of
schedulable time occurring on a CPU.  On a virtual cpu, that is affected
by the amount of physical cpu time the hypervisor schedules for a vcpu,
and can therefore advance in a very non-continuous way, depending on the
overall load on the host system.  It is, however, the only timebase that
gives the kernel a reasonable hope of determining how much cpu a process
actually got scheduled.

The net result is that the sched_clock timebase is 1) monotonic, 2)
loses arbitrary amounts of time against a system monotonic clock, 3)
per-cpu, with 4) arbitrary drift between different cpu's sched_clocks.

Tying the sched_clocks of different cpus together in any way loses these
properties, and just turns it into another system wide monotonic clock,
which seems redundant given that we already have one (I understand that
the relatively loose synchronization allows it to be implemented more
efficiently than a normal monotonic clock).

At the moment the x86 sched_clock is hooked through paravirt_ops so that
the underlying hypervisor can provide precise scheduled time
information, with the hope that the scheduler will use it to make better
decisions.  However if the scheduler needs to be lied to then I can do
that too, but it's a pity to throw away information that's available to it.

    J
--
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/