On 5/11/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
On Fri, May 11, 2007 at 07:18:25PM +, Pavel Machek wrote:
> Hi!
>
> > > Also notice that current cpus were not designed to work 300 years.
> > > When we have hw designed for 50 years+, we can start to worry.
On a related note, older
On Fri, May 11, 2007 at 07:18:25PM +, Pavel Machek wrote:
> Hi!
>
> > > Also notice that current cpus were not designed to work 300 years.
> > > When we have hw designed for 50 years+, we can start to worry.
> >
> > Indeed. CPU manufacturers don't seem to talk about it very much, and
> >
Hi!
> > Also notice that current cpus were not designed to work 300 years.
> > When we have hw designed for 50 years+, we can start to worry.
>
> Indeed. CPU manufacturers don't seem to talk about it very much, and
> searching for it with google on intel.com comes up with
>
> The failure
On Thu, 10 May 2007, Pavel Machek wrote:
>
> Also notice that current cpus were not designed to work 300 years.
> When we have hw designed for 50 years+, we can start to worry.
Indeed. CPU manufacturers don't seem to talk about it very much, and
searching for it with google on intel.com comes
Hi!
> >>You say there is "no danger of overflow", and I mostly
> >>agree that once
> >>we're talking about 64-bit values, the overflow issue
> >>simply doesn't
> >>exist, and furthermore the difference between 63 and
> >>64 bits is not really
> >>relevant, so there's no major reason to
Hi!
You say there is no danger of overflow, and I mostly
agree that once
we're talking about 64-bit values, the overflow issue
simply doesn't
exist, and furthermore the difference between 63 and
64 bits is not really
relevant, so there's no major reason to actively avoid
signed
On Thu, 10 May 2007, Pavel Machek wrote:
Also notice that current cpus were not designed to work 300 years.
When we have hw designed for 50 years+, we can start to worry.
Indeed. CPU manufacturers don't seem to talk about it very much, and
searching for it with google on intel.com comes up
Hi!
Also notice that current cpus were not designed to work 300 years.
When we have hw designed for 50 years+, we can start to worry.
Indeed. CPU manufacturers don't seem to talk about it very much, and
searching for it with google on intel.com comes up with
The failure rate and
On Fri, May 11, 2007 at 07:18:25PM +, Pavel Machek wrote:
Hi!
Also notice that current cpus were not designed to work 300 years.
When we have hw designed for 50 years+, we can start to worry.
Indeed. CPU manufacturers don't seem to talk about it very much, and
searching for it
On 5/11/07, Willy Tarreau [EMAIL PROTECTED] wrote:
On Fri, May 11, 2007 at 07:18:25PM +, Pavel Machek wrote:
Hi!
Also notice that current cpus were not designed to work 300 years.
When we have hw designed for 50 years+, we can start to worry.
On a related note, older technology is
Esben Nielsen wrote:
On Tue, 8 May 2007, Peter Williams wrote:
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
> > > On Sun, 6 May 2007, Ingo Molnar wrote:
> > > > * Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > > > So the _only_ valid way to handle timers is to
> >
On Tue, 8 May 2007, Johannes Stezenbach wrote:
On Tue, May 08, 2007, Esben Nielsen wrote:
This is contrary to C99 standeard annex H2.2
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf):
"An implementation that defines signed integer types as also being modulo
need
not detect
On Tue, May 08, 2007, Esben Nielsen wrote:
>
> This is contrary to C99 standeard annex H2.2
> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf):
>
> "An implementation that defines signed integer types as also being modulo
> need
> not detect integer overflow, in which case, only
On Tue, 8 May 2007, Peter Williams wrote:
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
>
>
> On Sun, 6 May 2007, Ingo Molnar wrote:
> >
> > * Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > > So the _only_ valid way to handle timers is to
> > > - either not
On Mon, 7 May 2007, Johannes Stezenbach wrote:
On Mon, May 07, 2007, Linus Torvalds wrote:
On Mon, 7 May 2007, Esben Nielsen wrote:
What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find
On Mon, 7 May 2007, Johannes Stezenbach wrote:
On Mon, May 07, 2007, Linus Torvalds wrote:
On Mon, 7 May 2007, Esben Nielsen wrote:
What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find
On Tue, 8 May 2007, Peter Williams wrote:
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at
On Tue, May 08, 2007, Esben Nielsen wrote:
This is contrary to C99 standeard annex H2.2
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf):
An implementation that defines signed integer types as also being modulo
need
not detect integer overflow, in which case, only integer
On Tue, 8 May 2007, Johannes Stezenbach wrote:
On Tue, May 08, 2007, Esben Nielsen wrote:
This is contrary to C99 standeard annex H2.2
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf):
An implementation that defines signed integer types as also being modulo
need
not detect
Esben Nielsen wrote:
On Tue, 8 May 2007, Peter Williams wrote:
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not
On Mon, May 07, 2007 at 09:28:32AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 7 May 2007, Esben Nielsen wrote:
> >
> > What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
> > can't find it. Maybe it is in the referred LIA-1 standeard, which I can't
> > find
> > with
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case "unsigned" is
better,
since it is
On Mon, 2007-05-07 at 19:52 +0530, Srivatsa Vaddagiri wrote:
> On Thu, May 03, 2007 at 08:53:47AM -0700, William Lee Irwin III wrote:
> > On Thu, May 03, 2007 at 08:23:18PM +0530, Srivatsa Vaddagiri wrote:
> > > And what about group scheduling extensions? Do you have plans to work on
> > > it? I
On Mon, 7 May 2007, Johannes Stezenbach wrote:
>
> One baffling example where gcc rewrites code is when
> conditionals depend on signed integer overflow:
Yes. This is one of my favourite beefs with gcc. Some of the optimization
decisions seem to make no sense.
Your example is a good one, but
On Mon, May 07, 2007, Linus Torvalds wrote:
> On Mon, 7 May 2007, Esben Nielsen wrote:
> >
> > What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
> > can't find it. Maybe it is in the referred LIA-1 standeard, which I can't
> > find
> > with google.
C99 defines unsigned
On Mon, 7 May 2007, Esben Nielsen wrote:
>
> What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
> can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find
> with google.
I don't worry about non-2's-complement machines (they don't exist, and
On Mon, 7 May 2007, Esben Nielsen wrote:
>
> I would hate to tell mission control for Mankind's first mission to another
> star to reboot every 200 years because "there is no need to worry about it."
I'd like to put it another way:
- if your mission to another star *depends* on every single
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
> I would hate to tell mission control for Mankind's first mission to
> another star to reboot every 200 years because "there is no need to
> worry about it."
ok, i need no other argument - fixed :-)
(btw., if anyone from the planning committee of
On Thu, May 03, 2007 at 08:53:47AM -0700, William Lee Irwin III wrote:
> On Thu, May 03, 2007 at 08:23:18PM +0530, Srivatsa Vaddagiri wrote:
> > And what about group scheduling extensions? Do you have plans to work on
> > it? I was begining to work on a prototype to do group scheduling based
> >
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case "unsigned" is better,
since it is bigger)
- or use wrapping
On Sat, 5 May 2007, Linus Torvalds wrote:
On Sat, 5 May 2007, Esben Nielsen wrote:
I have been wondering why you use usigned for timers anyway. It is also like
that in hrtimers. Why not use signed and avoid (almost) all worries about wrap
around issues. The trick is that when all
a < b
On Mon, 7 May 2007, Esben Nielsen wrote:
I would hate to tell mission control for Mankind's first mission to another
star to reboot every 200 years because there is no need to worry about it.
I'd like to put it another way:
- if your mission to another star *depends* on every single piece
On Mon, 7 May 2007, Esben Nielsen wrote:
What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find
with google.
I don't worry about non-2's-complement machines (they don't exist, and
likely
On Mon, May 07, 2007, Linus Torvalds wrote:
On Mon, 7 May 2007, Esben Nielsen wrote:
What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
can't find it. Maybe it is in the referred LIA-1 standeard, which I can't
find
with google.
C99 defines unsigned overflow
On Mon, 7 May 2007, Johannes Stezenbach wrote:
One baffling example where gcc rewrites code is when
conditionals depend on signed integer overflow:
Yes. This is one of my favourite beefs with gcc. Some of the optimization
decisions seem to make no sense.
Your example is a good one, but my
On Mon, 2007-05-07 at 19:52 +0530, Srivatsa Vaddagiri wrote:
On Thu, May 03, 2007 at 08:53:47AM -0700, William Lee Irwin III wrote:
On Thu, May 03, 2007 at 08:23:18PM +0530, Srivatsa Vaddagiri wrote:
And what about group scheduling extensions? Do you have plans to work on
it? I was
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case unsigned is
better,
since it is bigger)
On Mon, May 07, 2007 at 09:28:32AM -0700, Linus Torvalds wrote:
On Mon, 7 May 2007, Esben Nielsen wrote:
What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
can't find it. Maybe it is in the referred LIA-1 standeard, which I can't
find
with google.
I
On Sat, 5 May 2007, Linus Torvalds wrote:
On Sat, 5 May 2007, Esben Nielsen wrote:
I have been wondering why you use usigned for timers anyway. It is also like
that in hrtimers. Why not use signed and avoid (almost) all worries about wrap
around issues. The trick is that when all
a b
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case unsigned is better,
since it is bigger)
- or use wrapping
On Thu, May 03, 2007 at 08:53:47AM -0700, William Lee Irwin III wrote:
On Thu, May 03, 2007 at 08:23:18PM +0530, Srivatsa Vaddagiri wrote:
And what about group scheduling extensions? Do you have plans to work on
it? I was begining to work on a prototype to do group scheduling based
on CFS,
* Esben Nielsen [EMAIL PROTECTED] wrote:
I would hate to tell mission control for Mankind's first mission to
another star to reboot every 200 years because there is no need to
worry about it.
ok, i need no other argument - fixed :-)
(btw., if anyone from the planning committee of
Damien Wyart wrote:
Hello,
* Ingo Molnar <[EMAIL PROTECTED]> [2007-05-03 15:02]:
great! So it seems -v8 does improve OpenGL handling too :-)
What are your thoughts/plans concerning merging CFS into mainline ? Is
it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
change the
On Sun, 6 May 2007, Ingo Molnar wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > So the _only_ valid way to handle timers is to
> > - either not allow wrapping at all (in which case "unsigned" is better,
> >since it is bigger)
> > - or use wrapping explicitly, and use
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Just a hint: while your code here is correct, it is a good practise to
> check against < 0 instead, so that if for any reason you sometimes
> forget to cast to signed, the compiler will emit a warning stating
> that the condition is always false.
Hi Ingo,
On Sun, May 06, 2007 at 10:29:11AM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > So the _only_ valid way to handle timers is to
> > - either not allow wrapping at all (in which case "unsigned" is better,
> >since it is bigger)
> > - or use
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So the _only_ valid way to handle timers is to
> - either not allow wrapping at all (in which case "unsigned" is better,
>since it is bigger)
> - or use wrapping explicitly, and use unsigned arithmetic (which is
>well-defined in C) and do
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case unsigned is better,
since it is bigger)
- or use wrapping explicitly, and use unsigned arithmetic (which is
well-defined in C) and do
Hi Ingo,
On Sun, May 06, 2007 at 10:29:11AM +0200, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case unsigned is better,
since it is bigger)
- or use wrapping explicitly,
* Willy Tarreau [EMAIL PROTECTED] wrote:
Just a hint: while your code here is correct, it is a good practise to
check against 0 instead, so that if for any reason you sometimes
forget to cast to signed, the compiler will emit a warning stating
that the condition is always false. This
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case unsigned is better,
since it is bigger)
- or use wrapping explicitly, and use unsigned arithmetic
Damien Wyart wrote:
Hello,
* Ingo Molnar [EMAIL PROTECTED] [2007-05-03 15:02]:
great! So it seems -v8 does improve OpenGL handling too :-)
What are your thoughts/plans concerning merging CFS into mainline ? Is
it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
change the
On Sat, 5 May 2007, Esben Nielsen wrote:
>
> I have been wondering why you use usigned for timers anyway. It is also like
> that in hrtimers. Why not use signed and avoid (almost) all worries about wrap
> around issues. The trick is that when all
> a < b
> is be replaced by
> a - b < 0
>
On Wed, 2 May 2007, Ingo Molnar wrote:
* Balbir Singh <[EMAIL PROTECTED]> wrote:
The problem is with comparing a s64 values with (s64)ULONG_MAX, which
evaluates to -1. Then we check if exec_delta64 and fair_delta64 are
greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to
the
On Wed, 2 May 2007, Ingo Molnar wrote:
* Balbir Singh [EMAIL PROTECTED] wrote:
The problem is with comparing a s64 values with (s64)ULONG_MAX, which
evaluates to -1. Then we check if exec_delta64 and fair_delta64 are
greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to
the
On Sat, 5 May 2007, Esben Nielsen wrote:
I have been wondering why you use usigned for timers anyway. It is also like
that in hrtimers. Why not use signed and avoid (almost) all worries about wrap
around issues. The trick is that when all
a b
is be replaced by
a - b 0
the code
On Thu, 2007-05-03 at 08:53 -0700, William Lee Irwin III wrote:
>> Tong Li's Trio scheduler does a bit of this, though it doesn't seem to
>> have the mindshare cfs seems to have acquired.
>> The hyperlink seems to have broken, though:
>>
On Thu, 2007-05-03 at 08:53 -0700, William Lee Irwin III wrote:
> On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote:
> >> What are your thoughts/plans concerning merging CFS into mainline ? Is
> >> it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
> >> change the
On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote:
>> What are your thoughts/plans concerning merging CFS into mainline ? Is
>> it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
>> change the default scheduler rapidly (the discussion was about sd at
>> that time) to
Srivatsa Vaddagiri wrote:
On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote:
- EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they
know the length of work units
This is what I was thinking when I wrote earlier that EEVDF expects each
task will specify
Ingo Molnar wrote:
* Ting Yang <[EMAIL PROTECTED]> wrote:
Authors of this paper proposed a scheduler: Earlist Eligible Virtual
Deadline First (EEVDF). EEVDF uses exactly the same method as CFS to
track the execution of each running task. The only difference between
EEVDF and CFS is that
On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote:
> What are your thoughts/plans concerning merging CFS into mainline ? Is
> it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
> change the default scheduler rapidly (the discussion was about sd at
> that time) to get
On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote:
> - EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they
> know the length of work units
This is what I was thinking when I wrote earlier that EEVDF expects each
task will specify "length of each new request"
Hello,
* Ingo Molnar <[EMAIL PROTECTED]> [2007-05-03 15:02]:
> great! So it seems -v8 does improve OpenGL handling too :-)
What are your thoughts/plans concerning merging CFS into mainline ? Is
it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
change the default scheduler
* Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> I started up 12 glxgears to see the effect of CFS v8 on my Athlon64 X2
> 4200.
>
> Without this patch all the GL load was handled by the second core, the
> system only stressed the first core if other processes were also
> started, i.e. a
On Wed, May 02, 2007 at 11:18:45PM -0400, Ting Yang wrote:
> I just want to point out that ->wait_runtime, in fact, stores the lag of
> each task in CFS, except that it is also used by other things, and
> occasionally tweaked (heuristically ?). Under normal cases the sum of
> lags of all active
* Ting Yang <[EMAIL PROTECTED]> wrote:
> Authors of this paper proposed a scheduler: Earlist Eligible Virtual
> Deadline First (EEVDF). EEVDF uses exactly the same method as CFS to
> track the execution of each running task. The only difference between
> EEVDF and CFS is that EEVDF tries to
Hi!
*** Balbir Singh <[EMAIL PROTECTED]> wrote:
> The problem is with comparing a s64 values with (s64)ULONG_MAX, which
> evaluates to -1. Then we check if exec_delta64 and fair_delta64 are
> greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to
> the respective values.
ah,
Hi!
*** Balbir Singh [EMAIL PROTECTED] wrote:
The problem is with comparing a s64 values with (s64)ULONG_MAX, which
evaluates to -1. Then we check if exec_delta64 and fair_delta64 are
greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to
the respective values.
ah, indeed
* Ting Yang [EMAIL PROTECTED] wrote:
Authors of this paper proposed a scheduler: Earlist Eligible Virtual
Deadline First (EEVDF). EEVDF uses exactly the same method as CFS to
track the execution of each running task. The only difference between
EEVDF and CFS is that EEVDF tries to
On Wed, May 02, 2007 at 11:18:45PM -0400, Ting Yang wrote:
I just want to point out that -wait_runtime, in fact, stores the lag of
each task in CFS, except that it is also used by other things, and
occasionally tweaked (heuristically ?). Under normal cases the sum of
lags of all active
* Zoltan Boszormenyi [EMAIL PROTECTED] wrote:
I started up 12 glxgears to see the effect of CFS v8 on my Athlon64 X2
4200.
Without this patch all the GL load was handled by the second core, the
system only stressed the first core if other processes were also
started, i.e. a kernel
Hello,
* Ingo Molnar [EMAIL PROTECTED] [2007-05-03 15:02]:
great! So it seems -v8 does improve OpenGL handling too :-)
What are your thoughts/plans concerning merging CFS into mainline ? Is
it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
change the default scheduler
On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote:
- EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they
know the length of work units
This is what I was thinking when I wrote earlier that EEVDF expects each
task will specify length of each new request
On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote:
What are your thoughts/plans concerning merging CFS into mainline ? Is
it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
change the default scheduler rapidly (the discussion was about sd at
that time) to get more
Ingo Molnar wrote:
* Ting Yang [EMAIL PROTECTED] wrote:
Authors of this paper proposed a scheduler: Earlist Eligible Virtual
Deadline First (EEVDF). EEVDF uses exactly the same method as CFS to
track the execution of each running task. The only difference between
EEVDF and CFS is that
Srivatsa Vaddagiri wrote:
On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote:
- EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they
know the length of work units
This is what I was thinking when I wrote earlier that EEVDF expects each
task will specify
On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote:
What are your thoughts/plans concerning merging CFS into mainline ? Is
it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
change the default scheduler rapidly (the discussion was about sd at
that time) to get more
On Thu, 2007-05-03 at 08:53 -0700, William Lee Irwin III wrote:
On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote:
What are your thoughts/plans concerning merging CFS into mainline ? Is
it a bit premature to get it into 2.6.22 ? I remember Linus was ok to
change the default
On Thu, 2007-05-03 at 08:53 -0700, William Lee Irwin III wrote:
Tong Li's Trio scheduler does a bit of this, though it doesn't seem to
have the mindshare cfs seems to have acquired.
The hyperlink seems to have broken, though:
http://www.cs.duke.edu/~tongli/linux/linux-2.6.19.2-trio.patch
On Wed, May 02, 2007 at 11:06:34PM +0530, Srivatsa Vaddagiri wrote:
There is also p->wait_runtime which is taken into account when
calculating p->fair_key. So if p3 had waiting in runqueue for long
before, it can get to run quicker than 10ms later.
Virtual time is time from the
Li, Tong N wrote:
Thanks for the excellent explanation. I think EEVDF and many algs alike
assume global ordering of all tasks in the system (based on virtual
time), whereas CFS does so locally on each processor and relies on load
balancing to achieve fairness across processors. It'd achieve
Hi,
As encouraged by some of you, I have started implementing EEVDF.
However, I am quite new in this area, and may not be experienced enough
to get it through quickly. The main problems, I am facing now ,is how
to treat the semantics of yeild() and yield_to(). I probably will throw
a lot
Srivatsa Vaddagiri wrote:
I briefly went thr' the paper and my impression is it expect each task
to specify the length of each new request it initiates. Is that correct?
No, the timeslice l_i here serves as a granularity control w.r.t
responsiveness (or latency depends on how you interpret
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> Things are moving in good directions on all this as far as I'm
>> concerned. Moving according to Ting Yang's analysis should wrap up the
>> soundness concerns about intra-queue policy I've had. OTOH load
>> balancing I know much less about
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> The coincidental aspect would be that at the time it was written, the
> formal notion of lag was not being used particularly with respect to
> priorities and load weights. [...]
(nice levels for SCHED_OTHER are 'just' an add-on concept to
At some point in the past, Ting Yang wrote:
>> Based on my understanding, adopting something like EEVDF in CFS should
>> not be very difficult given their similarities, although I do not have
>> any idea on how this impacts the load balancing for SMP. Does this worth
>> a try?
>> Sorry for
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> Virtual time is time from the task's point of view, which it has spent
>> executing. ->wait_runtime is a device to subtract out time spent on
>> the runqueue but not running from what would otherwise be virtual time
>> to express lag,
> Based on my understanding, adopting something like EEVDF in CFS should
> not be very difficult given their similarities, although I do not have
> any idea on how this impacts the load balancing for SMP. Does this worth
> a try?
>
> Sorry for such a long email :-)
Thanks for the
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> > There is also p->wait_runtime which is taken into account when
> > calculating p->fair_key. So if p3 had waiting in runqueue for long
> > before, it can get to run quicker than 10ms later.
>
> Virtual time is time from the task's point of
On Tue, May 01, 2007 at 10:57:14PM -0400, Ting Yang wrote:
>> "A Proportional Share REsource Allocation Algorithm for Real-Time,
>> Time-Shared Systems", by Ion Stoica. You can find the paper here:
>> http://citeseer.ist.psu.edu/37752.html
On Wed, May 02, 2007 at 11:06:34PM +0530, Srivatsa
On Tue, May 01, 2007 at 10:57:14PM -0400, Ting Yang wrote:
> "A Proportional Share REsource Allocation Algorithm for Real-Time,
> Time-Shared Systems", by Ion Stoica. You can find the paper here:
> http://citeseer.ist.psu.edu/37752.html
Good paper ..thanks for the pointer.
I briefly went thr'
* Vegard Nossum <[EMAIL PROTECTED]> wrote:
> The sys_sched_yield_to() is not callable from userspace on i386
> because it is not part of the syscall table
> (arch/i386/kernel/syscall_table.S). This causes sysenter_entry
> (arch/i386/kernel/entry.S) to use the wrong count for nr_syscalls (320
On Tue, May 1, 2007 11:22 pm, Ingo Molnar wrote:
> As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome,
Hi,
The sys_sched_yield_to() is not callable from userspace on i386 because it
is not part of the syscall table (arch/i386/kernel/syscall_table.S). This
causes
Ingo Molnar wrote:
i'm pleased to announce release -v8 of the CFS scheduler patchset. (The
main goal of CFS is to implement "desktop scheduling" with as high
quality as technically possible.)
The CFS patch against v2.6.21.1 (or against v2.6.20.10) can be
downloaded from the usual place:
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> The problem is with comparing a s64 values with (s64)ULONG_MAX, which
> evaluates to -1. Then we check if exec_delta64 and fair_delta64 are
> greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to
> the respective values.
ah, indeed
Ingo Molnar wrote:
* Balbir Singh <[EMAIL PROTECTED]> wrote:
With -v7 I would run the n/n+1 test. Basically on a system with n
cpus, I would run n+1 tasks and see how their load is distributed. I
usually find that the last two tasks would get stuck on one CPU on the
system and would get half
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-05-01 at 23:22 +0200, Ingo Molnar wrote:
> > - interactivity: precise load calculation and load smoothing
>
> This seems to help quite a bit.
great :)
> (5 second top sample)
>
> 2636 root 15 -5 19148 15m 5324 R 73 1.5
* Ting Yang <[EMAIL PROTECTED]> wrote:
> My name is Ting Yang, a graduate student from UMASS. I am currently
> studying the linux scheduler and virtual memory manager to solve some
> page swapping problems. I am very excited with the new scheduler CFS.
> After I read through your code, I
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> With -v7 I would run the n/n+1 test. Basically on a system with n
> cpus, I would run n+1 tasks and see how their load is distributed. I
> usually find that the last two tasks would get stuck on one CPU on the
> system and would get half the cpu
1 - 100 of 150 matches
Mail list logo
