On Mon, 2007-07-23 at 09:15 +, Jan Glauber wrote:
> > > 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_proce
On Fri, 2007-07-20 at 09:22 +0200, Ingo Molnar wrote:
> * Paul Mackerras <[EMAIL PROTECTED]> wrote:
> > 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
* Paul Mackerras <[EMAIL PROTECTED]> wrote:
> 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
Paul Mackerras wrote:
> 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).
>
Sounds
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_cloc
On Thu, 2007-07-19 at 21:38 +0200, Ingo Molnar wrote:
> * Jan Glauber <[EMAIL PROTECTED]> wrote:
>
> > > 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 tha
* Jan Glauber <[EMAIL PROTECTED]> wrote:
> > 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.
>
> I'm n
On Thu, 2007-07-19 at 18:00 +0200, Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > > /*
> > > - * Monotonic_clock - returns # of nanoseconds passed since time_init()
> > > + * Scheduler clock - returns current time in nanosec units.
> > > + * Now based on virtual cpu t
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > /*
> > - * Monotonic_clock - returns # of nanoseconds passed since time_init()
> > + * Scheduler clock - returns current time in nanosec units.
> > + * Now based on virtual cpu time to only account time the guest
> > + * was actually running.
On Thu, Jul 19, 2007 at 08:29:06AM -0700, Jeremy Fitzhardinge wrote:
> > - * Monotonic_clock - returns # of nanoseconds passed since time_init()
> > + * Scheduler clock - returns current time in nanosec units.
> > + * Now based on virtual cpu time to only account time the guest
> > + * was actually
Jan Glauber wrote:
> This patch introduces a cpu time clock for s390 (only ticking
> if the virtual cpu is running) and bases the s390 implementation
> of sched_clock() on it.
>
> The times lice length on a virtual cpu can be anything
> between the calculated time slice and zero. In reality
> this
This patch introduces a cpu time clock for s390 (only ticking
if the virtual cpu is running) and bases the s390 implementation
of sched_clock() on it.
The times lice length on a virtual cpu can be anything
between the calculated time slice and zero. In reality
this doesn't seem to be problem, sinc
12 matches
Mail list logo
