public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ting Yang <tingy@cs.umass.edu>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	efault@gmx.de, linux-kernel@vger.kernel.org
Subject: Re: fair clock use in CFS
Date: Mon, 14 May 2007 16:20:45 -0400	[thread overview]
Message-ID: <4648C49D.3070909@cs.umass.edu> (raw)
In-Reply-To: <20070514112016.GW19966@holomorphy.com>


William Lee Irwin III wrote:
> On Mon, May 14, 2007 at 04:52:59PM +0530, Srivatsa Vaddagiri wrote:
>   
>> Doesn't EEVDF have the same issue? From the paper:
>> 	V(t) = 1/(w1 + w2 + ...wn)
>>     
>
> Who knows what I was smoking, then. I misremembered the scale factor
> as being on the other side of comparisons with the queue's clock. I'm
> suspicious of EEVDF's timekeeping now as well.
>
>   
Both CFS and EEVDF uses the queue virtual time (VT) to measure the total 
amount of work done so far, VT maps to different real time scale as the 
workload in the system varies. It provides a measure for task to check 
if it goes ahead or falls behind.

Suppose, each task p maintain its own  virtual time, which  is advance 
reverse proportional to its weight
    VT_p(t + 1)  = VT_p(t) + 1/w_p
(in fact, CFS uses this to calculate p->delta_mine, EEVDF uses this to 
decide the deadline for a given slice of work by adding l_p/w_p to 
virtual start time.)
At the time when VT_p(t) = VT(t), i.e. at time t, the virtual time of a 
task equals the virtual time of the queue, this task has received its 
entitled share in interval [0, t]. If VT_p(t) < VT(p), it falls behind 
than it should, otherwise it goes ahead than it should.

Both CFS and EEVDF uses this measure implicitly to decide when a task 
should be executed. The difference is that CFS allows the amount of 
carried out by a task of weight w_i to be continuously executed until it 
goes ahead what it should by a certain amount (tuned and scaled 
accordingly). While EEVDF has to give out a slice (since it is deadline 
driven), and forces a potential long work to be done in smaller slices 
and interleaved with other tasks. Combined with eligibility check, EEVDF 
provides better "fairness" (only in the sense that work spread out more 
evenly in relative short window, since nobody can continuously do more 
than l_i amount of work) with the overhead of _more_ context switches.

It is really difficult for me to say which one is better.  In 
particular, the current CFS implementation favors  higher weight tasks. 
The granularity used by higher weight task is scaled up, which allows it 
to go ahead more (as it is possibly more important and should make it 
finish as early as possible.), while lower weight task has no such 
ability. This makes a lot sense to me.


Ting

  parent reply	other threads:[~2007-05-14 20:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-14  8:33 fair clock use in CFS Srivatsa Vaddagiri
2007-05-14 10:29 ` William Lee Irwin III
2007-05-14 10:31   ` Ingo Molnar
2007-05-14 11:05     ` William Lee Irwin III
2007-05-14 11:22       ` Srivatsa Vaddagiri
2007-05-14 11:20         ` William Lee Irwin III
2007-05-14 12:04           ` Ingo Molnar
2007-05-14 23:57             ` William Lee Irwin III
2007-05-14 20:20           ` Ting Yang [this message]
2007-05-14 11:50       ` Ingo Molnar
2007-05-14 14:31         ` Daniel Hazelton
2007-05-14 15:02           ` Srivatsa Vaddagiri
2007-05-14 15:08           ` Ingo Molnar
2007-05-15  2:59           ` David Schwartz
2007-05-14 21:24         ` Ting Yang
2007-05-15  0:57           ` Ting Yang
2007-05-14 23:23         ` William Lee Irwin III
2007-05-14 11:10 ` Ingo Molnar
2007-05-14 13:04   ` Srivatsa Vaddagiri
2007-05-14 13:15     ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2007-05-14 15:02 Al Boldi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4648C49D.3070909@cs.umass.edu \
    --to=tingy@cs.umass.edu \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=vatsa@in.ibm.com \
    --cc=wli@holomorphy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox