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

[Ingo Molnar]

* Christian Borntraeger <borntraeger@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/