Messages in this thread | | | Subject | Re: [PATCH 1/7] cpu-timers: high-resolution CPU clocks for POSIX clock_* syscalls | From | Andi Kleen <> | Date | 14 Dec 2004 20:07:39 +0100 |
| |
Roland McGrath <roland@redhat.com> writes: > > /* > + * This is called on clock ticks and on context switches. > + * Bank in p->sched_time the ns elapsed since the last tick or switch. > + */ > +static void update_cpu_clock(task_t *p, runqueue_t *rq, > + unsigned long long now) > +{ > + unsigned long long last = max(p->timestamp, rq->timestamp_last_tick); > + p->sched_time += now - last; > +}
This will completely mess up the register allocation in schedule() long long on i386 forces basically everything else out onto the stack because it needs 4 aligned registers.
I suspect when you benchmark it it will become visibly slower.
In general it seems like a bad idea to polute the extremly critical fast paths in schedule with support for such an obscure operation. Is there really any real need for such a high resolution per process timer anyways? I have my doubts about it, I would suspect most apps are more interested in wall clock time.
I don't think this should be merged until a clear need from a useful application is demonstrated for it.
-Andi
- 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/
| |