lkml.org 
[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.083 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site