Re: No 100 HZ timer !

From: schwidefsky@de.ibm.com
Date: Wed Apr 11 2001 - 04:06:00 EST


>f) As noted, the account timers (task user/system times) would be much
>more accurate with the tick less approach. The cost is added code in
>both the system call and the schedule path.
>
>Tentative conclusions:
>
>Currently we feel that the tick less approach is not acceptable due to
>(f). We felt that this added code would NOT be welcome AND would, in a
>reasonably active system, have much higher overhead than any savings in
>not having a tick. Also (d) implies a list organization that will, at
>the very least, be harder to understand. (We have some thoughts here,
>but abandoned the effort because of (f).) We are, of course, open to
>discussion on this issue and all others related to the project
>objectives.
f) might be true on Intel based systems. At least for s/390 the situation
is a little bit different. Here is a extract from the s/390 part of the
timer patch:

       .macro UPDATE_ENTER_TIME reload
       la %r14,thread+_TSS_UTIME(%r9) # pointer to utime
       tm SP_PSW+1(%r15),0x01 # interrupting from user ?
       jno 0f # yes -> add to user time
       la %r14,8(%r14) # no -> add to system time
0: lm %r0,%r1,0(%r14) # load user/system time
       sl %r1,__LC_LAST_MARK+4 # subtract last time mark
       bc 3,BASED(1f) # borrow ?
       sl %r0,BASED(.Lc1)
1: sl %r0,__LC_LAST_MARK
       stck __LC_LAST_MARK # make a new mark
       al %r1,__LC_LAST_MARK+4 # add new mark -> added delta
       bc 12,BASED(2f) # carry ?
       al %r0,BASED(.Lc1)
2: al %r0,__LC_LAST_MARK
       stm %r0,%r1,0(%r14) # store updated user/system time
       clc __LC_LAST_MARK(8),__LC_JIFFY_TIMER # check if enough time
       jl 3f # passed for a jiffy update
       l %r1,BASED(.Ltime_warp)
       basr %r14,%r1
       .if \reload # reload != 0 for system call
       lm %r2,%r6,SP_R2(%r15) # reload clobbered parameters
       .endif
3:

       .macro UPDATE_LEAVE_TIME
       l %r1,BASED(.Ltq_timer) # test if tq_timer list is empty
       x %r1,0(%r1) # tq_timer->next != tq_timer ?
       jz 0f
       l %r1,BASED(.Ltq_timer_active)
       icm %r0,15,0(%r1) # timer event already added ?
       jnz 0f
       l %r1,BASED(.Ltq_pending)
       basr %r14,%r1
0: lm %r0,%r1,thread+_TSS_STIME(%r9) # load system time
       sl %r1,__LC_LAST_MARK+4 # subtract last time mark
       bc 3,BASED(1f) # borrow ?
       sl %r0,BASED(.Lc1)
1: sl %r0,__LC_LAST_MARK
       stck __LC_LAST_MARK # make new mark
       al %r1,__LC_LAST_MARK+4 # add new mark -> added delta
       bc 12,BASED(2f) # carry ?
       al %r0,BASED(.Lc1)
2: al %r0,__LC_LAST_MARK
       stm %r0,%r1,thread+_TSS_STIME(%r9) # store system time
       .endm

The two macros UPDATE_ENTER_TIME and UPDATE_LEAVE_TIMER are executed
on every system entry/exit. In the case that no special work has to
be done less then 31 instruction are executed in addition to the
normal system entry/exit code. Special work has to be done if more
time then 1/HZ has passed (call time_warp), or if tq_timer contains
an element (call tq_pending).
The accuracy of the timer events has not changed. It still is 1/HZ.
The only thing this patch does is to avoid unneeded interruptions.
I'd be happy if this could be combined with a new, more accurate
timing method.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

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



This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:15 EST