Ingo Molnar writes:
> CFS does measure time elapsed across task-sleep periods (and does
> something similar to what the old scheduler's 'sleep average'
> interactivity mechanism did), but that mechanism measures "time spent
> running during sleep", not "time spent idling".
PowerPC's sched_clock() currently measures real time. On POWER5 and
POWER6 machines we could change it to use a register called the "PURR"
(for Processor Utilization of Resources Register), which only measures
time spent while the partition is running. But the PURR has another
function as well: it measures the distribution of dispatch cycles
between the two hardware threads on each core when running in SMT
mode. That is, the cpu dispatches instructions from one thread or
the other (not both) on each CPU cycle, and each thread's PURR only
gets incremented on cycles where the cpu dispatches instructions for
that thread. So the sum of the two threads' PURRs adds up to real
time.
Do you think this makes the PURR more useful for CFS, or less? To me
it looks like this would mean that CFS can make a more equitable
distribution of CPU time if, for example, you had 3 runnable tasks on
a 2-core x dual-threaded machine (4 virtual CPUs).
BTW, what does "time spent running during sleep" mean? Does it mean
"time that other tasks are running while this task is sleeping"?
> still, CFS needs time measurement across idle periods as well, for
> another purpose: to be able to do precise task statistics for /proc.
> (for top, ps, etc.) So it's still true that sched_clock() should include
> idle periods too.
As with s390, 64-bit PowerPC also uses CONFIG_VIRT_CPU_ACCOUNTING.
That affects how tsk->utime and tsk->stime are accumulated (we call
account_user_time and account_system_time directly rather than calling
update_process_times) as well as the system hardirq/softirq time, idle
time, and stolen time.
When you say "precise task statistics for /proc", where are they
accumulated? I don't see any changes to the way that tsk->utime and
ctime are computed.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
