linux-kernel - Re: [patch 0/2] s390 related scheduler patches and questions

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

Message-ID: <20070823200526.GA8486@elte.hu>
Date:	Thu, 23 Aug 2007 22:05:26 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christian Borntraeger <borntraeger@...ibm.com>
Cc:	Jan Glauber <jan.glauber@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 0/2] s390 related scheduler patches and questions

* Christian Borntraeger <borntraeger@...ibm.com> wrote:

> Another question:
> 
> nanosecond resolution seems not ideal for 64bit values, at least if an 
> architecture has to do calculations. For example our cpu timer is 
> signed 64bit and bit 51 (63=LSB) steps by one each microsecond. To 
> create a nanosecond based timer we need: nsecs= clock*125/512 or nsecs 
> = clock/512*125. The first variant overflows in a time frame that is 
> still reasonable to be seen in practice (about 2 years if I made no 
> errors), the second variant introduces a stepping rate of 125ns. Of 
> course we could use nsec = (((((((clock/8)*5)/4)*5)/4)*5)/4), to have 
> a long overflow period and a 1.25ns stepping rate but this looks quite 
> ugly. Are you going to stick with nanosecond resolution? If yes, do 
> you think a stepping rate of 125ns is ok? Any chance to change the 
> scheduler resolution to microseconds? ;-)

there are noticeable accounting artifacts on fast boxes that do 
sub-microsecond scheduling, so getting the best sched_clock() resolution 
is certainly handy. (Also, nanoseconds gives us some rounding-error 
room.) But 0.125 usecs should still be fine.

the 2 years overflow is not an issue: you could solve that by only using 
the first 55 bits of the clock. This means the clock would wrap around 
every 1.14 years - the effects of that are that the "dont let time go 
backwards" code in the scheduler will ignore a very small interval 
(which happens at the wraparound) and will continue with the 
wrapped-around clock from that point on. The rq->clock itself is a true, 
monotonic 64-bit clock that wraps every 584.9 years.

[ and even after 584.9 years it should have no serious failure mode, as 
  the timestamps are used in a relative manner. The only, minimal effect 
  is on tasks that sleep for more than 584 years - which could get a few 
  millisecs less sleeper fairness share. I am not overly worried about
  getting bugreports about that in my lifetime though =B-) (unless
  someone gets serious about bio-cryogenics R&D, real soon.) ]

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