Messages in this thread | | | Date | Thu, 25 Jun 1998 12:28:31 +0200 | From | Pavel Machek <> | Subject | Re: Scheduler fixes |
| |
Hi!
> > Linux tries to measure times spend in > > processes... Somehow. Unfortunately, it is optimistic: it will show > > less than real values under some pretty common > > circumstances. (Application sleeping for short times and doing small > > ammount of processing is marked as eating 0% of system time. There are > > some applications which do this - for example ksame, qweb (and I think > > that everything using qt) - which do evil busy waiting.) > > on SMP this is different. User-space process time accounting uses a > different clock source on most architectures. (the local APIC clock on > Intel).
So SMP is already much more accurate than UP?
> btw, we could do _exact_ process accounting if we want to, at the price of > ~10-15 cycles per schedule(). we can just read the cycle counter (industry > standard on most leading CPUs ;), add the delta to the process and do the > math later, whenever someone (top) tries to access the values. This way we > could even differentiate between IRQ cycles, kernel cycles, kernel thread > cycles, idle cycles and user-space cycles. Is this an important and > fundamental enough feature to justify those 10-15 cycles?
I think so.
BUt you have to consider:
* tsc speed may change with time. * each processor can run on other speed. * this needs touching all architectures and adding 'get_time64()' function. I've done this for intel... * this brand new tsc system needs some calibration * not all CPUs have tsc. Would using jiffie+get_slow_timeoffset do the trick and still be fast enough on 486? Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |