On Tue, Jul 03, 2007 at 10:10:05AM +0200, Keith Packard wrote:
> On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote:
>
> > which allows xterm-spam (attached) to easily flood the xterm (without
> > any scrolling that would act as a throttle) and the xterm to flood Xorg.
...deleting the
On Tue, Jul 03, 2007 at 10:40:07AM +0200, Ingo Molnar wrote:
> yeah, i use gnome-terminal exclusively. But testers looking for CFS
> regressions do run every shell on the planet :-)
...and people running older kernels get different results (no surprise)
fwiw, I ran 'top' on 5 terminals with
On Tue, Jul 03, 2007 at 10:40:07AM +0200, Ingo Molnar wrote:
yeah, i use gnome-terminal exclusively. But testers looking for CFS
regressions do run every shell on the planet :-)
...and people running older kernels get different results (no surprise)
fwiw, I ran 'top' on 5 terminals with
On Tue, Jul 03, 2007 at 10:10:05AM +0200, Keith Packard wrote:
On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote:
which allows xterm-spam (attached) to easily flood the xterm (without
any scrolling that would act as a throttle) and the xterm to flood Xorg.
...deleting the offhand
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> ah. That indeed makes sense. It seems like the xterm doesnt process the
> Ctrl-C/Z keypresses _at all_ when it is 'spammed' with output. Normally,
> output 'spam' is throttled by the scroll buffer's overhead. But in
> Vegard's case, the printout
Ingo Molnar [EMAIL PROTECTED] writes:
ah. That indeed makes sense. It seems like the xterm doesnt process the
Ctrl-C/Z keypresses _at all_ when it is 'spammed' with output. Normally,
output 'spam' is throttled by the scroll buffer's overhead. But in
Vegard's case, the printout involves a
On 7/3/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
does it still get more CPU time than you'd expect it to get? A reniced
or SCHED_IDLE task will 'fill in' any idle time that it senses, so in
itself it's not an anomaly if a task gets 50% and FEH fills in the
remaining 50%. Does it still get CPU
* Keith Packard <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote:
>
> > which allows xterm-spam (attached) to easily flood the xterm
> > (without any scrolling that would act as a throttle) and the xterm
> > to flood Xorg.
>
> It's just an Xterm bug.
>
>
On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote:
> which allows xterm-spam (attached) to easily flood the xterm (without
> any scrolling that would act as a throttle) and the xterm to flood Xorg.
It's just an Xterm bug.
Xterm will look for X input if it ever manages to fill the input
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> This doesn't appear to be a CFS problem. I can reproduce the problem
> easily in virgin 2.6.22-rc7 by starting xterm-spam at nice -1 or
> better. As soon as xterm-spam can get enough CPU to keep the xterm
> fully busy, it's game over, the xterm
* Vegard Nossum <[EMAIL PROTECTED]> wrote:
> I'd also like to point out that [EMAIL PROTECTED] seems to draw more CPU
> than it should. Or, at least, in top, it shows up as using 50% CPU
> even though other processes are demanding as much as they can get. The
> FAH program should be running
On Mon, 2007-07-02 at 18:40 +0200, Vegard Nossum wrote:
> On 7/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > thx. As an initial matter, could you double-check whether your v18
> > kernel source has the patch below applied already?
> >
> > Ingo
> >
> > Index: linux/kernel/sched_fair.c
>
On 7/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
ok. Does the xterm slowdown get any better if you do:
echo 46 > /proc/sys/kernel/sched_features
? The default on v18 is:
echo 14 > /proc/sys/kernel/sched_features
No. The Ctrl-C still hangs between 1 and 3 seconds, again seemingly
On 7/2/07, Ingo Molnar [EMAIL PROTECTED] wrote:
ok. Does the xterm slowdown get any better if you do:
echo 46 /proc/sys/kernel/sched_features
? The default on v18 is:
echo 14 /proc/sys/kernel/sched_features
No. The Ctrl-C still hangs between 1 and 3 seconds, again seemingly
depending
On Mon, 2007-07-02 at 18:40 +0200, Vegard Nossum wrote:
On 7/2/07, Ingo Molnar [EMAIL PROTECTED] wrote:
thx. As an initial matter, could you double-check whether your v18
kernel source has the patch below applied already?
Ingo
Index: linux/kernel/sched_fair.c
* Vegard Nossum [EMAIL PROTECTED] wrote:
I'd also like to point out that [EMAIL PROTECTED] seems to draw more CPU
than it should. Or, at least, in top, it shows up as using 50% CPU
even though other processes are demanding as much as they can get. The
FAH program should be running with
* Mike Galbraith [EMAIL PROTECTED] wrote:
This doesn't appear to be a CFS problem. I can reproduce the problem
easily in virgin 2.6.22-rc7 by starting xterm-spam at nice -1 or
better. As soon as xterm-spam can get enough CPU to keep the xterm
fully busy, it's game over, the xterm
On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote:
which allows xterm-spam (attached) to easily flood the xterm (without
any scrolling that would act as a throttle) and the xterm to flood Xorg.
It's just an Xterm bug.
Xterm will look for X input if it ever manages to fill the input
* Keith Packard [EMAIL PROTECTED] wrote:
On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote:
which allows xterm-spam (attached) to easily flood the xterm
(without any scrolling that would act as a throttle) and the xterm
to flood Xorg.
It's just an Xterm bug.
Xterm will look
On 7/3/07, Ingo Molnar [EMAIL PROTECTED] wrote:
does it still get more CPU time than you'd expect it to get? A reniced
or SCHED_IDLE task will 'fill in' any idle time that it senses, so in
itself it's not an anomaly if a task gets 50% and FEH fills in the
remaining 50%. Does it still get CPU
* Vegard Nossum <[EMAIL PROTECTED]> wrote:
> > thx. As an initial matter, could you double-check whether your v18
> > kernel source has the patch below applied already?
>
> It does.
ok. Does the xterm slowdown get any better if you do:
echo 46 > /proc/sys/kernel/sched_features
? The
On 7/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
thx. As an initial matter, could you double-check whether your v18
kernel source has the patch below applied already?
Ingo
Index: linux/kernel/sched_fair.c
===
---
* Vegard Nossum <[EMAIL PROTECTED]> wrote:
> Resulting files at
> http://vegard.afraid.org:1104/pub/cfs/
>
> cfs-debug-info-2007.07.02-15:18:13Before running program
> cfs-debug-info-2007.07.02-15:19:51~10 secs after start
> cfs-debug-info-2007.07.02-15:20:54~1 minute after start
>
Vegard Nossum wrote:
Hello,
On 6/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
I have been running cfs-v18 for a couple of days now, and
On 7/2/07, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
On 02/07/07, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> I have been running cfs-v18 for a couple of days now, and today I
> stumbled upon a rather strange problem. Consider the following short
> program:
>
> while(1)
>
On 02/07/07, Vegard Nossum <[EMAIL PROTECTED]> wrote:
Hello,
On 6/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i'm pleased to announce release -v18 of the CFS scheduler patchset.
> As usual, any sort of feedback, bugreport, fix and suggestion is more
> than welcome!
I have been running
Hello,
On 6/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
I have been running cfs-v18 for a couple of days now, and today I
stumbled upon
Hello,
On 6/23/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
I have been running cfs-v18 for a couple of days now, and today I
stumbled upon a
On 02/07/07, Vegard Nossum [EMAIL PROTECTED] wrote:
Hello,
On 6/23/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
I have been running cfs-v18
On 7/2/07, Dmitry Adamushko [EMAIL PROTECTED] wrote:
On 02/07/07, Vegard Nossum [EMAIL PROTECTED] wrote:
I have been running cfs-v18 for a couple of days now, and today I
stumbled upon a rather strange problem. Consider the following short
program:
while(1)
printf(%ld\r, 1000 *
Vegard Nossum wrote:
Hello,
On 6/23/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
I have been running cfs-v18 for a couple of days now, and
* Vegard Nossum [EMAIL PROTECTED] wrote:
Resulting files at
http://vegard.afraid.org:1104/pub/cfs/
cfs-debug-info-2007.07.02-15:18:13Before running program
cfs-debug-info-2007.07.02-15:19:51~10 secs after start
cfs-debug-info-2007.07.02-15:20:54~1 minute after start
On 7/2/07, Ingo Molnar [EMAIL PROTECTED] wrote:
thx. As an initial matter, could you double-check whether your v18
kernel source has the patch below applied already?
Ingo
Index: linux/kernel/sched_fair.c
===
---
* Vegard Nossum [EMAIL PROTECTED] wrote:
thx. As an initial matter, could you double-check whether your v18
kernel source has the patch below applied already?
It does.
ok. Does the xterm slowdown get any better if you do:
echo 46 /proc/sys/kernel/sched_features
? The default on v18
Hi Ingo,
On Sun, Jul 01, 2007 at 10:45:01AM +0200, Ingo Molnar wrote:
> could you check whether your current v18 CFS tree has the fix below
> included? I discovered it right after having released v18 so i updated
> the v18 files in place - but maybe you downloaded an early version? I
> thought
Willy,
could you check whether your current v18 CFS tree has the fix below
included? I discovered it right after having released v18 so i updated
the v18 files in place - but maybe you downloaded an early version? I
thought it's relatively harmless, that it would only affect SCHED_IDLE
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> I've accidentally discovered a problem with -v18.
>
> Some time ago, I wrote a small program to prevent my laptop from
> entering low-power mode, and noticed that after upgrading my laptop's
> kernel from 2.4.20.9+cfs-v6 to
* Willy Tarreau [EMAIL PROTECTED] wrote:
Ingo,
I've accidentally discovered a problem with -v18.
Some time ago, I wrote a small program to prevent my laptop from
entering low-power mode, and noticed that after upgrading my laptop's
kernel from 2.4.20.9+cfs-v6 to 2.4.20.14+cfs-v18, it
Willy,
could you check whether your current v18 CFS tree has the fix below
included? I discovered it right after having released v18 so i updated
the v18 files in place - but maybe you downloaded an early version? I
thought it's relatively harmless, that it would only affect SCHED_IDLE
Hi Ingo,
On Sun, Jul 01, 2007 at 10:45:01AM +0200, Ingo Molnar wrote:
could you check whether your current v18 CFS tree has the fix below
included? I discovered it right after having released v18 so i updated
the v18 files in place - but maybe you downloaded an early version? I
thought
Ingo,
I've accidentally discovered a problem with -v18.
Some time ago, I wrote a small program to prevent my laptop from entering
low-power mode, and noticed that after upgrading my laptop's kernel from
2.4.20.9+cfs-v6 to 2.4.20.14+cfs-v18, it completely freezes if I run this
program.
The
Ingo,
I've accidentally discovered a problem with -v18.
Some time ago, I wrote a small program to prevent my laptop from entering
low-power mode, and noticed that after upgrading my laptop's kernel from
2.4.20.9+cfs-v6 to 2.4.20.14+cfs-v18, it completely freezes if I run this
program.
The
* Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote:
> > -Message d'origine-
> > De : [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar
> > Envoyé : 22 juin 2007 18:02
> >
> > i'm pleased to announce release -v18 of the CFS scheduler patchset.
> >
> > The
* Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote:
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Ingo Molnar
Envoyé : 22 juin 2007 18:02
i'm pleased to announce release -v18 of the CFS scheduler patchset.
The rolled-up CFS patch
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar
> Envoyé : 22 juin 2007 18:02
>
> i'm pleased to announce release -v18 of the CFS scheduler patchset.
>
> The rolled-up CFS patch against today's -git kernel,
> v2.6.22-rc5,
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > the main reason is the sched debugging stuff:
>
> That would serve to explain the 18% growth on x86_64. But why did
> i386 grow by much more: 29%? I'd be suspecting all the new 64-bit
> arithmetic.
this is what i see on 32-bit:
text
On Tue, 26 Jun 2007 10:38:13 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > - __exit_signal() does apparently-unlocked 64-bit arith. Is there
> > some implicit locking here or do we not care about the occasional
> > race-induced inaccuracy?
>
> do you mean the
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> So I locally generated the diff to take -mm up to the above version of
> CFS.
thx. I released a diff against mm2:
http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-rc4-mm2-v18.patch
but indeed the -git diff serves you better if you
* Andrew Morton [EMAIL PROTECTED] wrote:
So I locally generated the diff to take -mm up to the above version of
CFS.
thx. I released a diff against mm2:
http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-rc4-mm2-v18.patch
but indeed the -git diff serves you better if you
On Tue, 26 Jun 2007 10:38:13 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
- __exit_signal() does apparently-unlocked 64-bit arith. Is there
some implicit locking here or do we not care about the occasional
race-induced inaccuracy?
do you mean the tsk-se.sum_exec_runtime addition,
* Andrew Morton [EMAIL PROTECTED] wrote:
the main reason is the sched debugging stuff:
That would serve to explain the 18% growth on x86_64. But why did
i386 grow by much more: 29%? I'd be suspecting all the new 64-bit
arithmetic.
this is what i see on 32-bit:
textdata
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Ingo Molnar
Envoyé : 22 juin 2007 18:02
i'm pleased to announce release -v18 of the CFS scheduler patchset.
The rolled-up CFS patch against today's -git kernel,
v2.6.22-rc5, v2.6.22-rc4-mm2,
On Sat, 23 Jun 2007 00:20:36 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
>
> > > kernel/sched.c:745:28: sched_idletask.c: No such file or directory
> >
> > Ahh and this happens with [1], grabbing sched_idletask.c from .18 one
> > solves
> > the
2007/6/24, Ingo Molnar <[EMAIL PROTECTED]>:
* Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
> Anyway, I've discovered with great pleasure that CFS has also the
> SCHED_ISO priority. I may have missed something, but I don't remember
> to have read this in any of the CFS release notes :). For
2007/6/24, Ingo Molnar [EMAIL PROTECTED]:
* Antonino Ingargiola [EMAIL PROTECTED] wrote:
Anyway, I've discovered with great pleasure that CFS has also the
SCHED_ISO priority. I may have missed something, but I don't remember
to have read this in any of the CFS release notes :). For me this
On Sat, 23 Jun 2007 00:20:36 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
kernel/sched.c:745:28: sched_idletask.c: No such file or directory
Ahh and this happens with [1], grabbing sched_idletask.c from .18 one
solves
the problem...
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > > I have no idea about what version brought that unexpected
> > > behaviour, but it's clearly something which needs to be tracked
> > > down.
> >
> > hm, the two problems might be related. Could you try v17 perhaps? In
> > v18 i have 'unified'
Hi Ingo,
On Sun, Jun 24, 2007 at 05:52:14PM +0200, Ingo Molnar wrote:
>
> * Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > Today I had a little time to try CFS again (last time it was -v9!). I
> > ran it on top of 2.6.20.14, and simply tried ocbench again. You
> > remember ? With -v9, I ran
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Today I had a little time to try CFS again (last time it was -v9!). I
> ran it on top of 2.6.20.14, and simply tried ocbench again. You
> remember ? With -v9, I ran 64 processes which all progressed very
> smoothly. With -v18, it's not the case
* Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
> Anyway, I've discovered with great pleasure that CFS has also the
> SCHED_ISO priority. I may have missed something, but I don't remember
> to have read this in any of the CFS release notes :). For me this is a
> really useful feature.
2007/6/23, Ingo Molnar <[EMAIL PROTECTED]>:
* Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
> 2007/6/23, Ingo Molnar <[EMAIL PROTECTED]>:
> >
> >i'm pleased to announce release -v18 of the CFS scheduler patchset.
>
> I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
>
2007/6/23, Ingo Molnar [EMAIL PROTECTED]:
* Antonino Ingargiola [EMAIL PROTECTED] wrote:
2007/6/23, Ingo Molnar [EMAIL PROTECTED]:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
task to
* Antonino Ingargiola [EMAIL PROTECTED] wrote:
Anyway, I've discovered with great pleasure that CFS has also the
SCHED_ISO priority. I may have missed something, but I don't remember
to have read this in any of the CFS release notes :). For me this is a
really useful feature. Thanks.
* Willy Tarreau [EMAIL PROTECTED] wrote:
Today I had a little time to try CFS again (last time it was -v9!). I
ran it on top of 2.6.20.14, and simply tried ocbench again. You
remember ? With -v9, I ran 64 processes which all progressed very
smoothly. With -v18, it's not the case anymore.
Hi Ingo,
On Sun, Jun 24, 2007 at 05:52:14PM +0200, Ingo Molnar wrote:
* Willy Tarreau [EMAIL PROTECTED] wrote:
Today I had a little time to try CFS again (last time it was -v9!). I
ran it on top of 2.6.20.14, and simply tried ocbench again. You
remember ? With -v9, I ran 64 processes
* Willy Tarreau [EMAIL PROTECTED] wrote:
I have no idea about what version brought that unexpected
behaviour, but it's clearly something which needs to be tracked
down.
hm, the two problems might be related. Could you try v17 perhaps? In
v18 i have 'unified' all the sched.c's
* Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
> 2007/6/23, Ingo Molnar <[EMAIL PROTECTED]>:
> >
> >i'm pleased to announce release -v18 of the CFS scheduler patchset.
>
> I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
> task to SCHED_IDLE or SCHED_BATCH priority
Hi Ingo,
On Sat, Jun 23, 2007 at 12:02:02AM +0200, Ingo Molnar wrote:
>
> i'm pleased to announce release -v18 of the CFS scheduler patchset.
>
> The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5,
> v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the
> usual
Hi,
2007/6/23, Ingo Molnar <[EMAIL PROTECTED]>:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
task to SCHED_IDLE or SCHED_BATCH priority under CFS?
Thanks,
~ Antonio
-
To unsubscribe from this
On Saturday 23 June 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> patching file kernel/softirq.c
>> patching file kernel/sysctl.c
>> The next patch would delete the file l/kernel/sched.c,
>> which does not exist! Assume -R? [n]
>>
>> How to proceed?
>
>oops - just ignore
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> patching file kernel/softirq.c
> patching file kernel/sysctl.c
> The next patch would delete the file l/kernel/sched.c,
> which does not exist! Assume -R? [n]
>
> How to proceed?
oops - just ignore it, or re-download the patch (i fixed it).
* Gene Heskett [EMAIL PROTECTED] wrote:
patching file kernel/softirq.c
patching file kernel/sysctl.c
The next patch would delete the file l/kernel/sched.c,
which does not exist! Assume -R? [n]
How to proceed?
oops - just ignore it, or re-download the patch (i fixed it).
Ingo
-
On Saturday 23 June 2007, Ingo Molnar wrote:
* Gene Heskett [EMAIL PROTECTED] wrote:
patching file kernel/softirq.c
patching file kernel/sysctl.c
The next patch would delete the file l/kernel/sched.c,
which does not exist! Assume -R? [n]
How to proceed?
oops - just ignore it, or
Hi,
2007/6/23, Ingo Molnar [EMAIL PROTECTED]:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
task to SCHED_IDLE or SCHED_BATCH priority under CFS?
Thanks,
~ Antonio
-
To unsubscribe from this
Hi Ingo,
On Sat, Jun 23, 2007 at 12:02:02AM +0200, Ingo Molnar wrote:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5,
v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the
usual place:
* Antonino Ingargiola [EMAIL PROTECTED] wrote:
2007/6/23, Ingo Molnar [EMAIL PROTECTED]:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
I'm running -v18 on 2.6.22-rc5, no problems so far. How can I change a
task to SCHED_IDLE or SCHED_BATCH priority under CFS?
pick
On Friday 22 June 2007, Ingo Molnar wrote:
>i'm pleased to announce release -v18 of the CFS scheduler patchset.
>
>The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5,
>v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the
>usual place:
>
>
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> > kernel/sched.c:745:28: sched_idletask.c: No such file or directory
>
> Ahh and this happens with [1], grabbing sched_idletask.c from .18 one solves
> the problem...
oops, indeed - i've fixed up the -git patch:
23 Haz 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
> Hi Ingo;
>
> 23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
> > As usual, any sort of feedback, bugreport, fix and suggestion is more
> > than welcome!
>
> [EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
> CHK
Hi Ingo;
23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
> As usual, any sort of feedback, bugreport, fix and suggestion is more
> than welcome!
[EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL
Hi Ingo;
23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
[EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL
23 Haz 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
Hi Ingo;
23 Haz 2007 Cts tarihinde, Ingo Molnar şunları yazmıştı:
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
[EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
CHK include/linux/version.h
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
kernel/sched.c:745:28: sched_idletask.c: No such file or directory
Ahh and this happens with [1], grabbing sched_idletask.c from .18 one solves
the problem...
oops, indeed - i've fixed up the -git patch:
On Friday 22 June 2007, Ingo Molnar wrote:
i'm pleased to announce release -v18 of the CFS scheduler patchset.
The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5,
v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the
usual place:
84 matches
Mail list logo
