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 techno
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
> > sea
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 actively
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 integ
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 inte
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 all
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
with
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 goog
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 bigg
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 wa
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
likely
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 p
* 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 Ma
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
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 e
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
i
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 unsigne
* 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. Th
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 wrappi
* 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
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
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 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
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 defa
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 g
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 "len
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 m
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"
(http://l
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 rapi
* 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 kern
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 _d
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, i
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 task's
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 str
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 o
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 it
* 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 (n
* 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 th
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 s
* 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, whether
> 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 excellent
* 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 Vadd
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 sy
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 1
* 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 thin
* 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 time
On Tue, May 01, 2007 at 10:57:14PM -0400, 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?
>
>
Ingo Molnar wrote:
Changes since -v7:
- powerpc debug output and build warning fixes (Balbir Singh)
- documentation fixes (Zach Carter)
- interactivity: precise load calculation and load smoothing
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome,
On Wednesday 02 May 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> > I noticed a (harmless) bounds warning triggered by the reduction in
>> > size of array->bitmap. Patchlet below.
>>
>> I just checked my logs, and it appears my workload didn't trigger this
>> one Mike. [..
On Wednesday 02 May 2007, Mike Galbraith wrote:
>On Wed, 2007-05-02 at 04:03 -0400, Gene Heskett wrote:
>> I just checked my logs, and it appears my workload didn't trigger this one
>> Mike.
>
>It's just a build time compiler warning.
Duh. I have a couple of pages of "may be used uninitialized" w
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> > I noticed a (harmless) bounds warning triggered by the reduction in
> > size of array->bitmap. Patchlet below.
>
> I just checked my logs, and it appears my workload didn't trigger this
> one Mike. [...]
yeah: this is a build-time warning and it
On Wed, 2007-05-02 at 04:03 -0400, Gene Heskett wrote:
> I just checked my logs, and it appears my workload didn't trigger this one
> Mike.
It's just a build time compiler warning.
> Ingo asked for a 0-100 rating, where 0 is mainline as I recall it, and 100 is
> the best of the breed. I'll gi
On Wednesday 02 May 2007, Mike Galbraith 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.
>
>(5 second top sample)
>
> 2636 root 15 -5 19148 15m 5324 R 73 1.5 1:42.29 0
> ama
On Wednesday 02 May 2007, Mike Galbraith wrote:
>On Tue, 2007-05-01 at 23:22 +0200, 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.)
>
>...
>
>> As
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.
(5 second top sample)
2636 root 15 -5 19148 15m 5324 R 73 1.5 1:42.29 0 amarok_libvisua
5440 root 20 0 320m 36m 8388 S 18
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > As usual, any sort of feedback, bugreport, fix and suggestion is
> > more than welcome,
>
> Greetings,
>
> I noticed a (harmless) bounds warning triggered by the reduction in
> size of array->bitmap. Patchlet below.
thanks, applied! Your patch
On Tue, 2007-05-01 at 23:22 +0200, 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.)
...
> As usual, any sort of feedback, bugreport, fix and sugges
On Tue, May 01, 2007 at 10:57:14PM -0400, Ting Yang 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 tha
Hi Ting,
On Tue, May 01, 2007 at 10:57:14PM -0400, Ting Yang wrote:
>
> Hi, Ingo
>
> 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 C
Hi, Ingo
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 think that you might be interested in
re
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:
http://people.redhat
75 matches
Mail list logo
