Russell King wrote:
>
> Rogier Wolff writes:
> > Alan Cox wrote:
> > > What better interactivity ;)
> > Thus to me, 2.4 FEELS much less interactive. When I move windows they
> > don't follow the mouse in real-time.
>
> Interesting observation: in a scrolling rxvt, kernel 2.0 is smoother than
>
Russell King wrote:
Rogier Wolff writes:
Alan Cox wrote:
What better interactivity ;)
Thus to me, 2.4 FEELS much less interactive. When I move windows they
don't follow the mouse in real-time.
Interesting observation: in a scrolling rxvt, kernel 2.0 is smoother than
2.2, which is
Rogier Wolff writes:
> Alan Cox wrote:
> > What better interactivity ;)
> Thus to me, 2.4 FEELS much less interactive. When I move windows they
> don't follow the mouse in real-time.
Interesting observation: in a scrolling rxvt, kernel 2.0 is smoother than
2.2, which is smoother than 2.4. I
Rogier Wolff writes:
Alan Cox wrote:
What better interactivity ;)
Thus to me, 2.4 FEELS much less interactive. When I move windows they
don't follow the mouse in real-time.
Interesting observation: in a scrolling rxvt, kernel 2.0 is smoother than
2.2, which is smoother than 2.4. I hope
Alan Cox wrote:
> > How much of that is due to the fact that the 2.4.0 scheduler interrupts
> > processes more often than 2.2.x? Is the better interactivity worth the
> > slight drop in performance?
>
> What better interactivity ;)
Indeed!
On my dual Celeron workstation, 2.4 looks to me as if
Alan Cox wrote:
How much of that is due to the fact that the 2.4.0 scheduler interrupts
processes more often than 2.2.x? Is the better interactivity worth the
slight drop in performance?
What better interactivity ;)
Indeed!
On my dual Celeron workstation, 2.4 looks to me as if it is
On Tuesday 12 December 2000 13:38, Linus Torvalds wrote:
> On Tue, 12 Dec 2000, Steven Cole wrote:
> > Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
>
> Actually, do it with
>
> make -j3 'MAKE=make -j3' bzImage
>
> A single "-j3" won't do much. It will only build three
On Tue, 12 Dec 2000, Steven Cole wrote:
>
> Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
Actually, do it with
make -j3 'MAKE=make -j3' bzImage
A single "-j3" won't do much. It will only build three directories at a
time, and you'll never see much load. But doing it
On Tuesday 12 December 2000 11:40, Linus Torvalds wrote:
> On Tue, 12 Dec 2000, Steven Cole wrote:
> > Executive summary: SMP 2.4.0 is 2% faster than SMP 2.2.18.
>
> > I ran X and KDE 2.0 during the tests to provide a greater though
> > reproducable load on the tested kernel.
>
> You might want
On Tue, 12 Dec 2000, Steven Cole wrote:
>
> Executive summary: SMP 2.4.0 is 2% faster than SMP 2.2.18.
Note that kernel compilation really isn't a very relevant benchmark,
because percentage differences in this range can be basically just noise:
things like driver version differences that
On Monday 11 December 2000 11:46, Alan Cox wrote:
>
> Its an interesting demo that 2.4 has some performance problems since 2.2
> is slower than 2.0 although nowdays not much.
Results for SMP 2.2.18 vs SMP 2.4.0-test12 are in.
I repeated my earlier tests on a much faster dual P-III machine.
Helge Hafting wrote:
>Steven Cole wrote:
>[...]
>>Simple question here, and risking displaying great ignorance:
>>Does it make sense to use make -jN where N is much greater than the
>>number of CPUs?
>
>No, but it makes sense to have N at least one more than the number of
>cpus,
>if you have the
On Tue, 12 Dec 2000, Rik van Riel wrote:
> On Mon, 11 Dec 2000, Steven Cole wrote:
>
> > Building kernels is something we do so frequently and this test
> > is so easy to reproduce is why I performed it in the first
> > place. I think it may be as good a test of real performance as
> > some of
Steven Cole wrote:
[...]
> Simple question here, and risking displaying great ignorance:
> Does it make sense to use make -jN where N is much greater than the
> number of CPUs?
No, but it makes sense to have N at least one more than the number of
cpus,
if you have the memory. This because your
On Mon, 11 Dec 2000, Steven Cole wrote:
> Building kernels is something we do so frequently and this test
> is so easy to reproduce is why I performed it in the first
> place. I think it may be as good a test of real performance as
> some of the more formal benchmarks. Comments anyone?
Just
On Mon, 11 Dec 2000, Steven Cole wrote:
Building kernels is something we do so frequently and this test
is so easy to reproduce is why I performed it in the first
place. I think it may be as good a test of real performance as
some of the more formal benchmarks. Comments anyone?
Just one
Steven Cole wrote:
[...]
Simple question here, and risking displaying great ignorance:
Does it make sense to use make -jN where N is much greater than the
number of CPUs?
No, but it makes sense to have N at least one more than the number of
cpus,
if you have the memory. This because your
On Tue, 12 Dec 2000, Rik van Riel wrote:
On Mon, 11 Dec 2000, Steven Cole wrote:
Building kernels is something we do so frequently and this test
is so easy to reproduce is why I performed it in the first
place. I think it may be as good a test of real performance as
some of the more
Helge Hafting wrote:
Steven Cole wrote:
[...]
Simple question here, and risking displaying great ignorance:
Does it make sense to use make -jN where N is much greater than the
number of CPUs?
No, but it makes sense to have N at least one more than the number of
cpus,
if you have the memory.
On Monday 11 December 2000 11:46, Alan Cox wrote:
Its an interesting demo that 2.4 has some performance problems since 2.2
is slower than 2.0 although nowdays not much.
Results for SMP 2.2.18 vs SMP 2.4.0-test12 are in.
I repeated my earlier tests on a much faster dual P-III machine.
On Tuesday 12 December 2000 11:40, Linus Torvalds wrote:
On Tue, 12 Dec 2000, Steven Cole wrote:
Executive summary: SMP 2.4.0 is 2% faster than SMP 2.2.18.
I ran X and KDE 2.0 during the tests to provide a greater though
reproducable load on the tested kernel.
You might want to do the
On Tue, 12 Dec 2000, Steven Cole wrote:
Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
Actually, do it with
make -j3 'MAKE=make -j3' bzImage
A single "-j3" won't do much. It will only build three directories at a
time, and you'll never see much load. But doing it
On Tuesday 12 December 2000 13:38, Linus Torvalds wrote:
On Tue, 12 Dec 2000, Steven Cole wrote:
Task: make -j3 bzImage for 2.4.0-test12-pre7 kernel tree.
Actually, do it with
make -j3 'MAKE=make -j3' bzImage
A single "-j3" won't do much. It will only build three directories at a
On Mon, 11 Dec 2000, Steven Cole wrote:
> On Mon, 11 Dec 2000, Mike Galbraith wrote:
> > On Mon, 11 Dec 2000, Steven Cole wrote:
> > > I have a SMP (dual P-III 733Mhz) machine at work, but it will be
> > > unavailable for testing for a few more days. I suspect that 2.4.0-test12
> > > will do
On Mon, 11 Dec 2000, Mike Galbraith wrote:
> On Mon, 11 Dec 2000, Steven Cole wrote:
> > I have a SMP (dual P-III 733Mhz) machine at work, but it will be
> > unavailable for testing for a few more days. I suspect that 2.4.0-test12
> > will do better than 2.2.18 with 2 CPUs. I'll know in a few
On Mon, 11 Dec 2000, Steven Cole wrote:
> I have a SMP (dual P-III 733Mhz) machine at work, but it will be
> unavailable for testing for a few more days. I suspect that 2.4.0-test12
> will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
>
> Building kernels is something we do so
Aaron Tiensivu wrote:
>Rerun the 2.4.0 with kgcc to be fair. :)
John Fremlin wrote:
>Two points: (1) gcc 2.95 makes slightly slower code than egcs-1.1
>(according to benchmarks on gcc.gnu.org) so compile 2.4 kernel with
>egcs for a fairer comparison. (2) The new VM was a performance
Ok, several
> How much of that is due to the fact that the 2.4.0 scheduler interrupts
> processes more often than 2.2.x? Is the better interactivity worth the
> slight drop in performance?
What better interactivity ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Mon, Dec 11, 2000 at 04:38:11PM -0200, Rik van Riel wrote:
> On 11 Dec 2000, John Fremlin wrote:
>
> > Two points: [snipped]
>
>
> Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> for the VM doesn't make any sense since it doesn't really excercise
> the VM
On Mon, 11 Dec 2000, Alan Cox wrote:
> > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> > for the VM doesn't make any sense since it doesn't really excercise
> > the VM in any way...
>
> Its an interesting demo that 2.4 has some performance problems since 2.2
> is slower
On Mon, 11 Dec 2000, Alan Cox wrote:
> > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> > for the VM doesn't make any sense since it doesn't really excercise
> > the VM in any way...
>
> Its an interesting demo that 2.4 has some performance problems
> since 2.2 is slower
In article <[EMAIL PROTECTED]> you wrote:
>> Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
>> for the VM doesn't make any sense since it doesn't really excercise
>> the VM in any way...
> Its an interesting demo that 2.4 has some performance problems since 2.2
> is slower than
Alan Cox wrote:
>
> > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> > for the VM doesn't make any sense since it doesn't really excercise
> > the VM in any way...
>
> Its an interesting demo that 2.4 has some performance problems since 2.2
> is slower than 2.0 although
> Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> for the VM doesn't make any sense since it doesn't really excercise
> the VM in any way...
Its an interesting demo that 2.4 has some performance problems since 2.2
is slower than 2.0 although nowdays not much.
-
To
On 11 Dec 2000, John Fremlin wrote:
> Two points: [snipped]
Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
for the VM doesn't make any sense since it doesn't really excercise
the VM in any way...
If you want to measure, or even just bitch about, the VM, you should
Steven Cole <[EMAIL PROTECTED]> writes:
[...]
> In each case, the task and the tools used are the same. The only
> difference was the kernel used. In both cases, 2.2.18 won by 3%.
> Its comparing apples to apples and oranges to oranges. Granted 3%
> isn't very much, but I would have guessed
Steven Cole [EMAIL PROTECTED] writes:
[...]
In each case, the task and the tools used are the same. The only
difference was the kernel used. In both cases, 2.2.18 won by 3%.
Its comparing apples to apples and oranges to oranges. Granted 3%
isn't very much, but I would have guessed that
On 11 Dec 2000, John Fremlin wrote:
Two points: [snipped]
Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
for the VM doesn't make any sense since it doesn't really excercise
the VM in any way...
If you want to measure, or even just bitch about, the VM, you should
Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
for the VM doesn't make any sense since it doesn't really excercise
the VM in any way...
Its an interesting demo that 2.4 has some performance problems since 2.2
is slower than 2.0 although nowdays not much.
-
To unsubscribe
Alan Cox wrote:
Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
for the VM doesn't make any sense since it doesn't really excercise
the VM in any way...
Its an interesting demo that 2.4 has some performance problems since 2.2
is slower than 2.0 although nowdays not
On Mon, 11 Dec 2000, Alan Cox wrote:
Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
for the VM doesn't make any sense since it doesn't really excercise
the VM in any way...
Its an interesting demo that 2.4 has some performance problems
since 2.2 is slower than 2.0
On Mon, 11 Dec 2000, Alan Cox wrote:
Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
for the VM doesn't make any sense since it doesn't really excercise
the VM in any way...
Its an interesting demo that 2.4 has some performance problems since 2.2
is slower than 2.0
On Mon, Dec 11, 2000 at 04:38:11PM -0200, Rik van Riel wrote:
On 11 Dec 2000, John Fremlin wrote:
Two points: [snipped]
Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
for the VM doesn't make any sense since it doesn't really excercise
the VM in any
How much of that is due to the fact that the 2.4.0 scheduler interrupts
processes more often than 2.2.x? Is the better interactivity worth the
slight drop in performance?
What better interactivity ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Aaron Tiensivu wrote:
Rerun the 2.4.0 with kgcc to be fair. :)
John Fremlin wrote:
Two points: (1) gcc 2.95 makes slightly slower code than egcs-1.1
(according to benchmarks on gcc.gnu.org) so compile 2.4 kernel with
egcs for a fairer comparison. (2) The new VM was a performance
Ok, several
On Mon, 11 Dec 2000, Steven Cole wrote:
I have a SMP (dual P-III 733Mhz) machine at work, but it will be
unavailable for testing for a few more days. I suspect that 2.4.0-test12
will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
Building kernels is something we do so
On Mon, 11 Dec 2000, Mike Galbraith wrote:
On Mon, 11 Dec 2000, Steven Cole wrote:
I have a SMP (dual P-III 733Mhz) machine at work, but it will be
unavailable for testing for a few more days. I suspect that 2.4.0-test12
will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
On Mon, 11 Dec 2000, Steven Cole wrote:
On Mon, 11 Dec 2000, Mike Galbraith wrote:
On Mon, 11 Dec 2000, Steven Cole wrote:
I have a SMP (dual P-III 733Mhz) machine at work, but it will be
unavailable for testing for a few more days. I suspect that 2.4.0-test12
will do better than
Aaron Tiensivu wrote:
>| 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc).
>| 2.4.0-test12-pre7 was compiled with gcc 2.95.3.
>
>That's your answer right there.
>GCC 2.95.3 compiles much slower than kgcc.
>
>Rerun the 2.4.0 with kgcc to be fair. :)
Actually, it is fair. There are really two
| 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc).
| 2.4.0-test12-pre7 was compiled with gcc 2.95.3.
That's your answer right there.
GCC 2.95.3 compiles much slower than kgcc.
Rerun the 2.4.0 with kgcc to be fair. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
files were unchanged during the tests.
A make clean was performed before each test.
The test machine was not connected to a network during the tests.
Test machine: single processor P-III (450 Mhz), 192MB, IDE disk (ST317221A).
Conclusion: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
using
files were unchanged during the tests.
A make clean was performed before each test.
The test machine was not connected to a network during the tests.
Test machine: single processor P-III (450 Mhz), 192MB, IDE disk (ST317221A).
Conclusion: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
using
Aaron Tiensivu wrote:
| 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc).
| 2.4.0-test12-pre7 was compiled with gcc 2.95.3.
That's your answer right there.
GCC 2.95.3 compiles much slower than kgcc.
Rerun the 2.4.0 with kgcc to be fair. :)
Actually, it is fair. There are really two results,
53 matches
Mail list logo
