public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [patch 0/2] s390 related scheduler patches and questions
@ 2007-08-23 19:26 Christian Borntraeger
  2007-08-23 19:28 ` [patch 1/2] virtual sched_clock() for s390 Christian Borntraeger
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Christian Borntraeger @ 2007-08-23 19:26 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Jan Glauber, Martin Schwidefsky, linux-kernel

Hello Ingo,

Thanks you for applying the accouting fix.

I looked into Jans sched_clock prototype, and 
here is an update for sched_clock on s390. This patch applies on
current git, but should not go in before 2.6.23 as this change
is not trivial. The patch itself is independent from other patches
and survived my tests. The current approach is to have a
monotonic timer, that is only increased if the cpu is backed by
a real cpu. If idle, the sched_clock does not increase. The last
discussion did not result in a statement, if that is ok for you.

I tried to make the accouting work without the array.c patch I posted
recently. Therefore, I added a second patch that removes a sanity
checkin the scheduler (already seen). The patch is probably nothing for 
upstream but with this patch the accouting for s390 seems to work
regarding steal time, even without CONFIG_VIRT_CPU_TIME (as long as 
CONFIG_VIRT_TIMER is set). You wrote this part is necessary for broken
TSCs on x86.
Unfortunately, we currently call scheduler tick using the
tod clock and not the virtual clock and a change would take some time.
Removing this specific check seems to help. Will it break anything?

Would you accept a patch, that removes checks and let architecture code 
sanitize broken hardware values? That would allow non-broken timers to 
directly report to the scheduler.

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? ;-)


Christian

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-08-23 20:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-23 19:26 [patch 0/2] s390 related scheduler patches and questions Christian Borntraeger
2007-08-23 19:28 ` [patch 1/2] virtual sched_clock() for s390 Christian Borntraeger
2007-08-23 19:29 ` [patch 2/2] Let process accouting trust sched_clock Christian Borntraeger
2007-08-23 20:05 ` [patch 0/2] s390 related scheduler patches and questions Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox