* Re: 2.6.0-test4-mm5
2003-09-03 6:18 2.6.0-test4-mm5 Andrew Morton
@ 2003-09-03 7:17 ` Christian Axelsson
2003-09-03 18:29 ` 2.6.0-test4-mm5 William Lee Irwin III
2003-09-03 16:12 ` 2.6.0-test4-mm5 Adrian Bunk
` (5 subsequent siblings)
6 siblings, 1 reply; 36+ messages in thread
From: Christian Axelsson @ 2003-09-03 7:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
How is the work on CPU scheduler selection coming along? It would be a
Good Thing (TM) to have in this one imho.
- --
Christan Axelsson
smiler@lanil.mine.nu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQE/VZV5yqbmAWw8VdkRAvr1AJ4mEWvJJg2S8jIMk5OOBx+/kHmgtACg4CG2
YLVDbf13vBtm6uFNoQUZG3M=
=81tT
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5
2003-09-03 7:17 ` 2.6.0-test4-mm5 Christian Axelsson
@ 2003-09-03 18:29 ` William Lee Irwin III
0 siblings, 0 replies; 36+ messages in thread
From: William Lee Irwin III @ 2003-09-03 18:29 UTC (permalink / raw)
To: Christian Axelsson; +Cc: Andrew Morton, linux-kernel, linux-mm
On Wed, Sep 03, 2003 at 09:17:13AM +0200, Christian Axelsson wrote:
> How is the work on CPU scheduler selection coming along? It would be a
> Good Thing (TM) to have in this one imho.
No idea if anyone's doing it, but it should be relatively easy to do.
-- wli
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-03 6:18 2.6.0-test4-mm5 Andrew Morton
2003-09-03 7:17 ` 2.6.0-test4-mm5 Christian Axelsson
@ 2003-09-03 16:12 ` Adrian Bunk
2003-09-03 16:32 ` [PATCH] 2.6.0-test4-mm5 Jeff Garzik
2003-09-03 17:02 ` 2.6.0-test4-mm5: SCSI imm driver doesn't compile Adrian Bunk
` (4 subsequent siblings)
6 siblings, 1 reply; 36+ messages in thread
From: Adrian Bunk @ 2003-09-03 16:12 UTC (permalink / raw)
To: Andrew Morton, davem; +Cc: linux-kernel, linux-net, jgarzik
I got the following compile error (using gcc 2.95) in 2.6.0-test4-mm5
(but it seems to come from Linus' tree):
<-- snip -->
...
CC [M] drivers/net/sungem.o
drivers/net/sungem.c:2444: duplicate initializer
drivers/net/sungem.c:2444: (near initialization for `gem_ethtool_ops.get_link')
make[2]: *** [drivers/net/sungem.o] Error 1
<-- snip -->
It seems gcc is right, there are two .get_link members in this struct:
<-- snip -->
...
static struct ethtool_ops gem_ethtool_ops = {
.get_drvinfo = gem_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_settings = gem_get_settings,
.set_settings = gem_set_settings,
.nway_reset = gem_nway_reset,
.get_link = gem_get_link,
.get_msglevel = gem_get_msglevel,
.set_msglevel = gem_set_msglevel,
};
...
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH] Re: 2.6.0-test4-mm5
2003-09-03 16:12 ` 2.6.0-test4-mm5 Adrian Bunk
@ 2003-09-03 16:32 ` Jeff Garzik
2003-09-03 16:46 ` Benjamin Herrenschmidt
2003-09-04 3:21 ` David S. Miller
0 siblings, 2 replies; 36+ messages in thread
From: Jeff Garzik @ 2003-09-03 16:32 UTC (permalink / raw)
To: davem; +Cc: Adrian Bunk, Andrew Morton, linux-kernel, linux-net, benh
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Adrian Bunk wrote:
> It seems gcc is right, there are two .get_link members in this struct:
>
>
> <-- snip -->
>
> ...
> static struct ethtool_ops gem_ethtool_ops = {
David, would you look over this patch and apply/modify?
I would prefer to use the generic ethtool_op_get_link, because (a)
sungem is already using netif_carrier_xxx, and (b) if ->get_link ever
returns an incorrect value, that signals a netif_carrier_xxx bug exists.
As a tangent, gem_pcs_interrupt appears to call netif_carrier_xxx but
not set gem->lstate. David/Ben, is that a bug?
Thanks,
Jeff
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 645 bytes --]
===== drivers/net/sungem.c 1.44 vs edited =====
--- 1.44/drivers/net/sungem.c Sun Aug 24 08:58:18 2003
+++ edited/drivers/net/sungem.c Wed Sep 3 12:28:30 2003
@@ -2416,13 +2416,6 @@
return 0;
}
-static u32 gem_get_link(struct net_device *dev)
-{
- struct gem *gp = dev->priv;
-
- return (gp->lstate == link_up);
-}
-
static u32 gem_get_msglevel(struct net_device *dev)
{
struct gem *gp = dev->priv;
@@ -2441,7 +2434,6 @@
.get_settings = gem_get_settings,
.set_settings = gem_set_settings,
.nway_reset = gem_nway_reset,
- .get_link = gem_get_link,
.get_msglevel = gem_get_msglevel,
.set_msglevel = gem_set_msglevel,
};
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH] Re: 2.6.0-test4-mm5
2003-09-03 16:32 ` [PATCH] 2.6.0-test4-mm5 Jeff Garzik
@ 2003-09-03 16:46 ` Benjamin Herrenschmidt
2003-09-03 23:31 ` Jeff Garzik
2003-09-04 3:21 ` David S. Miller
1 sibling, 1 reply; 36+ messages in thread
From: Benjamin Herrenschmidt @ 2003-09-03 16:46 UTC (permalink / raw)
To: Jeff Garzik, David S. Miller
Cc: Adrian Bunk, Andrew Morton, linux-kernel mailing list, linux-net
> As a tangent, gem_pcs_interrupt appears to call netif_carrier_xxx but
> not set gem->lstate. David/Ben, is that a bug?
Looks like it is, David, you are the one who knows the PCS stuff ...
BTW. David: Any reason why you wouldn't let me change all occurences
of spin_{lock,unlock}_irq into the ...{save,restore} versions ?
I don't like force re-enabling interrupts the way we do it now with
spin_unlock_irq() the way we do it now. Among other things, that
breaks SA_INTERRUPT semantics and that breaks some pet project of
mine which is to run the IRQ handler with interrupts off when the
kernel stack is below a given threshold (to limit interrupt depth)
Ben.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH] Re: 2.6.0-test4-mm5
2003-09-03 16:46 ` Benjamin Herrenschmidt
@ 2003-09-03 23:31 ` Jeff Garzik
2003-09-04 7:29 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 36+ messages in thread
From: Jeff Garzik @ 2003-09-03 23:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: David S. Miller, Adrian Bunk, Andrew Morton,
linux-kernel mailing list, linux-net
Benjamin Herrenschmidt wrote:
> BTW. David: Any reason why you wouldn't let me change all occurences
> of spin_{lock,unlock}_irq into the ...{save,restore} versions ?
IMO... even though you do lose a tiny bit of performance, I definitely
prefer the save/restore versions.
It allows the arch a lot more flexibility, so I even have a [weak]
argument that {save,restore} variants increase portability. And it's
safer, as I like to avoid code which winds up doing (as it passes
through layers) spin_unlock_irq() followed by spin_unlock_irqrestore().
Jeff
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH] Re: 2.6.0-test4-mm5
2003-09-03 23:31 ` Jeff Garzik
@ 2003-09-04 7:29 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 36+ messages in thread
From: Benjamin Herrenschmidt @ 2003-09-04 7:29 UTC (permalink / raw)
To: Jeff Garzik
Cc: David S. Miller, Adrian Bunk, Andrew Morton,
linux-kernel mailing list, linux-net
On Thu, 2003-09-04 at 01:31, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > BTW. David: Any reason why you wouldn't let me change all occurences
> > of spin_{lock,unlock}_irq into the ...{save,restore} versions ?
>
>
> IMO... even though you do lose a tiny bit of performance, I definitely
> prefer the save/restore versions.
I'm not even sure you actually lose perfs... at least on ppc ;)
Ben.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] Re: 2.6.0-test4-mm5
2003-09-03 16:32 ` [PATCH] 2.6.0-test4-mm5 Jeff Garzik
2003-09-03 16:46 ` Benjamin Herrenschmidt
@ 2003-09-04 3:21 ` David S. Miller
1 sibling, 0 replies; 36+ messages in thread
From: David S. Miller @ 2003-09-04 3:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bunk, akpm, linux-kernel, linux-net, benh
On Wed, 03 Sep 2003 12:32:41 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:
> David, would you look over this patch and apply/modify?
Applied, thanks Jeff.
> I would prefer to use the generic ethtool_op_get_link, because (a)
> sungem is already using netif_carrier_xxx, and (b) if ->get_link ever
> returns an incorrect value, that signals a netif_carrier_xxx bug exists.
Agreed.
> As a tangent, gem_pcs_interrupt appears to call netif_carrier_xxx but
> not set gem->lstate. David/Ben, is that a bug?
Doesn't really matter, I don't think the rest of the PCS code even
cares about the setting of gem-lstate.
^ permalink raw reply [flat|nested] 36+ messages in thread
* 2.6.0-test4-mm5: SCSI imm driver doesn't compile
2003-09-03 6:18 2.6.0-test4-mm5 Andrew Morton
2003-09-03 7:17 ` 2.6.0-test4-mm5 Christian Axelsson
2003-09-03 16:12 ` 2.6.0-test4-mm5 Adrian Bunk
@ 2003-09-03 17:02 ` Adrian Bunk
2003-09-04 13:30 ` Arnaldo Carvalho de Melo
2003-09-03 23:08 ` 2.6.0-test4-mm5 Diego Calleja García
` (3 subsequent siblings)
6 siblings, 1 reply; 36+ messages in thread
From: Adrian Bunk @ 2003-09-03 17:02 UTC (permalink / raw)
To: Andrew Morton, Arnaldo Carvalho de Melo
Cc: linux-kernel, campbell, linux-scsi
The following compile error (tested with gcc 2.95) seems to come from
Linus' tree:
<-- snip -->
...
CC [M] drivers/scsi/imm.o
In file included from drivers/scsi/imm.c:55:
drivers/scsi/imm.h:105: duplicate array index in initializer
drivers/scsi/imm.h:105: (near initialization for `IMM_MODE_STRING')
make[2]: *** [drivers/scsi/imm.o] Error 1
<-- snip -->
The problem is the following code in imm.h (with
CONFIG_SCSI_IZIP_EPP16 enabled):
<-- snip -->
...
static char *IMM_MODE_STRING[] =
{
[IMM_AUTODETECT] = "Autodetect",
[IMM_NIBBLE] = "SPP",
[IMM_PS2] = "PS/2",
[IMM_EPP_8] = "EPP 8 bit",
[IMM_EPP_16] = "EPP 16 bit",
#ifdef CONFIG_SCSI_IZIP_EPP16
[IMM_EPP_16] = "EPP 16 bit",
#else
[IMM_EPP_32] = "EPP 32 bit",
#endif
[IMM_UNKNOWN] = "Unknown",
};
...
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5: SCSI imm driver doesn't compile
2003-09-03 17:02 ` 2.6.0-test4-mm5: SCSI imm driver doesn't compile Adrian Bunk
@ 2003-09-04 13:30 ` Arnaldo Carvalho de Melo
2003-09-04 13:52 ` Jan-Benedict Glaw
2003-09-04 17:50 ` [new patch] " Adrian Bunk
0 siblings, 2 replies; 36+ messages in thread
From: Arnaldo Carvalho de Melo @ 2003-09-04 13:30 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, campbell, linux-scsi
Em Wed, Sep 03, 2003 at 07:02:56PM +0200, Adrian Bunk escreveu:
> The following compile error (tested with gcc 2.95) seems to come from
> Linus' tree:
>
> <-- snip -->
>
> ...
> CC [M] drivers/scsi/imm.o
> In file included from drivers/scsi/imm.c:55:
> drivers/scsi/imm.h:105: duplicate array index in initializer
> drivers/scsi/imm.h:105: (near initialization for `IMM_MODE_STRING')
> make[2]: *** [drivers/scsi/imm.o] Error 1
>
> <-- snip -->
>
> The problem is the following code in imm.h (with
> CONFIG_SCSI_IZIP_EPP16 enabled):
>
> <-- snip -->
>
> ...
> static char *IMM_MODE_STRING[] =
> {
> [IMM_AUTODETECT] = "Autodetect",
> [IMM_NIBBLE] = "SPP",
> [IMM_PS2] = "PS/2",
> [IMM_EPP_8] = "EPP 8 bit",
> [IMM_EPP_16] = "EPP 16 bit",
> #ifdef CONFIG_SCSI_IZIP_EPP16
> [IMM_EPP_16] = "EPP 16 bit",
> #else
> [IMM_EPP_32] = "EPP 32 bit",
> #endif
> [IMM_UNKNOWN] = "Unknown",
> };
> ...
>
> <-- snip -->
Original code was:
static char *IMM_MODE_STRING[] =
{
"Autodetect",
"SPP",
"PS/2",
"EPP 8 bit",
"EPP 16 bit",
#ifdef CONFIG_SCSI_IZIP_EPP16
"EPP 16 bit",
#else
"EPP 32 bit",
#endif
"Unknown"};
I just converted it to the more safe c99 init style, but haven't noticed
the original bug, that is "EPP 16 bit" was duplicated... But this is already
fixed by Andrew Morton on current Linus bk tree.
Thanks Andrew for fixing, Adrian for noticing.
- Arnaldo
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5: SCSI imm driver doesn't compile
2003-09-04 13:30 ` Arnaldo Carvalho de Melo
@ 2003-09-04 13:52 ` Jan-Benedict Glaw
2003-09-04 14:30 ` Christoph Hellwig
2003-09-04 17:50 ` [new patch] " Adrian Bunk
1 sibling, 1 reply; 36+ messages in thread
From: Jan-Benedict Glaw @ 2003-09-04 13:52 UTC (permalink / raw)
To: linux-kernel, linux-scsi
Cc: Arnaldo Carvalho de Melo, Adrian Bunk, Andrew Morton, campbell
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Thu, 2003-09-04 10:30:56 -0300, Arnaldo Carvalho de Melo <acme@conectiva.com.br>
wrote in message <20030904133056.GA2411@conectiva.com.br>:
> Em Wed, Sep 03, 2003 at 07:02:56PM +0200, Adrian Bunk escreveu:
> > The following compile error (tested with gcc 2.95) seems to come from
> > Linus' tree:
>
> I just converted it to the more safe c99 init style, but haven't noticed
C99 style is
.element = initializer,
not
[element] = initializer,
which is a GNU/GCCism.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5: SCSI imm driver doesn't compile
2003-09-04 13:52 ` Jan-Benedict Glaw
@ 2003-09-04 14:30 ` Christoph Hellwig
2003-09-04 14:54 ` Jan-Benedict Glaw
0 siblings, 1 reply; 36+ messages in thread
From: Christoph Hellwig @ 2003-09-04 14:30 UTC (permalink / raw)
To: linux-kernel, linux-scsi, Arnaldo Carvalho de Melo, Adrian Bunk,
Andrew Morton, campbell
On Thu, Sep 04, 2003 at 03:52:56PM +0200, Jan-Benedict Glaw wrote:
> C99 style is
>
> .element = initializer,
>
> not
> [element] = initializer,
>
> which is a GNU/GCCism.
We're talking about arrays here..
.element obviously never works for arrays and [constant] never
works for structs..
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5: SCSI imm driver doesn't compile
2003-09-04 14:30 ` Christoph Hellwig
@ 2003-09-04 14:54 ` Jan-Benedict Glaw
0 siblings, 0 replies; 36+ messages in thread
From: Jan-Benedict Glaw @ 2003-09-04 14:54 UTC (permalink / raw)
To: linux-kernel, linux-scsi
Cc: Christoph Hellwig, Arnaldo Carvalho de Melo, Adrian Bunk,
Andrew Morton, campbell
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
On Thu, 2003-09-04 15:30:23 +0100, Christoph Hellwig <hch@infradead.org>
wrote in message <20030904153023.A32549@infradead.org>:
> On Thu, Sep 04, 2003 at 03:52:56PM +0200, Jan-Benedict Glaw wrote:
> > C99 style is
> >
> > .element = initializer,
> >
> > not
> > [element] = initializer,
> >
> > which is a GNU/GCCism.
>
> We're talking about arrays here..
*plonk* I stand corrected... I'm sorry...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* [new patch] Re: 2.6.0-test4-mm5: SCSI imm driver doesn't compile
2003-09-04 13:30 ` Arnaldo Carvalho de Melo
2003-09-04 13:52 ` Jan-Benedict Glaw
@ 2003-09-04 17:50 ` Adrian Bunk
1 sibling, 0 replies; 36+ messages in thread
From: Adrian Bunk @ 2003-09-04 17:50 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Andrew Morton, linux-kernel, campbell,
linux-scsi
On Thu, Sep 04, 2003 at 10:30:56AM -0300, Arnaldo Carvalho de Melo wrote:
>...
> I just converted it to the more safe c99 init style, but haven't noticed
> the original bug, that is "EPP 16 bit" was duplicated... But this is already
> fixed by Andrew Morton on current Linus bk tree.
>
> Thanks Andrew for fixing, Adrian for noticing.
Andrews patch removed the first IMM_EPP_16 line in the array.
This isn't correct especially in the !CONFIG_SCSI_IZIP_EPP16 case,
reading all uses of this array (IMM_MODE_STRING is used to print the
corresponding string in printks).
If I'm not misunderstanding it, CONFIG_SCSI_IZIP_EPP16 means "use 16bit
even when 32bit is requested".
It seems the right solution is
static char *IMM_MODE_STRING[] =
{
[IMM_AUTODETECT] = "Autodetect",
[IMM_NIBBLE] = "SPP",
[IMM_PS2] = "PS/2",
[IMM_EPP_8] = "EPP 8 bit",
[IMM_EPP_16] = "EPP 16 bit",
#ifdef CONFIG_SCSI_IZIP_EPP16
[IMM_EPP_32] = "EPP 16 bit",
#else
[IMM_EPP_32] = "EPP 32 bit",
#endif
[IMM_UNKNOWN] = "Unknown",
};
A patch against the current BK tree is below.
> - Arnaldo
cu
Adrian
--- linux-2.6.0-test4/drivers/scsi/imm.h.old 2003-09-04 19:47:23.000000000 +0200
+++ linux-2.6.0-test4/drivers/scsi/imm.h 2003-09-04 19:48:05.000000000 +0200
@@ -100,8 +100,9 @@
[IMM_NIBBLE] = "SPP",
[IMM_PS2] = "PS/2",
[IMM_EPP_8] = "EPP 8 bit",
-#ifdef CONFIG_SCSI_IZIP_EPP16
[IMM_EPP_16] = "EPP 16 bit",
+#ifdef CONFIG_SCSI_IZIP_EPP16
+ [IMM_EPP_32] = "EPP 16 bit",
#else
[IMM_EPP_32] = "EPP 32 bit",
#endif
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-03 6:18 2.6.0-test4-mm5 Andrew Morton
` (2 preceding siblings ...)
2003-09-03 17:02 ` 2.6.0-test4-mm5: SCSI imm driver doesn't compile Adrian Bunk
@ 2003-09-03 23:08 ` Diego Calleja García
2003-09-04 1:32 ` 2.6.0-test4-mm5 Nick Piggin
2003-09-04 2:04 ` 2.6.0-test4-mm5 Mike Fedyk
2003-09-04 1:30 ` 2.6.0-test4-mm5 Bill Huey
` (2 subsequent siblings)
6 siblings, 2 replies; 36+ messages in thread
From: Diego Calleja García @ 2003-09-03 23:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <akpm@osdl.org> escribió:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>
> . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> in evaluating the stability, efficacy and relative performance of Nick's
> work.
>
> We're looking for feedback on the subjective behaviour and on the usual
> server benchmarks please.
I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
skips that didn't happened before, big pauses in X...gcc starves anything else.
-mm4 was better there.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5
2003-09-03 23:08 ` 2.6.0-test4-mm5 Diego Calleja García
@ 2003-09-04 1:32 ` Nick Piggin
2003-09-04 18:23 ` 2.6.0-test4-mm5 Diego Calleja García
2003-09-04 2:04 ` 2.6.0-test4-mm5 Mike Fedyk
1 sibling, 1 reply; 36+ messages in thread
From: Nick Piggin @ 2003-09-04 1:32 UTC (permalink / raw)
To: Diego Calleja García; +Cc: Andrew Morton, linux-kernel
Diego Calleja García wrote:
>El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <akpm@osdl.org> escribió:
>
>
>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>>
>>. Dropped out Con's CPU scheduler work, added Nick's. This is to help us
>> in evaluating the stability, efficacy and relative performance of Nick's
>> work.
>>
>> We're looking for feedback on the subjective behaviour and on the usual
>> server benchmarks please.
>>
>>
>
>
>I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
>skips that didn't happened before, big pauses in X...gcc starves anything else.
>-mm4 was better there.
>
>
Hmm... what's heavy gcc load?
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-04 1:32 ` 2.6.0-test4-mm5 Nick Piggin
@ 2003-09-04 18:23 ` Diego Calleja García
2003-09-04 19:08 ` 2.6.0-test4-mm5 Mike Fedyk
2003-09-05 15:36 ` 2.6.0-test4-mm5 Martin Schlemmer
0 siblings, 2 replies; 36+ messages in thread
From: Diego Calleja García @ 2003-09-04 18:23 UTC (permalink / raw)
To: Nick Piggin; +Cc: akpm, linux-kernel
El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <piggin@cyberone.com.au> escribió:
> Hmm... what's heavy gcc load?
make -j25 with 256 MB RAM.
My X server is reniced at -1; but reniced X to -10 and it didn't helped;
-j15 was better (less swapping) but still I saw various mp3 & mouse skips.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-04 18:23 ` 2.6.0-test4-mm5 Diego Calleja García
@ 2003-09-04 19:08 ` Mike Fedyk
2003-09-05 15:36 ` 2.6.0-test4-mm5 Martin Schlemmer
1 sibling, 0 replies; 36+ messages in thread
From: Mike Fedyk @ 2003-09-04 19:08 UTC (permalink / raw)
To: Diego Calleja Garc?a; +Cc: Nick Piggin, akpm, linux-kernel
On Thu, Sep 04, 2003 at 08:23:19PM +0200, Diego Calleja Garc?a wrote:
> El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <piggin@cyberone.com.au> escribi?:
>
> > Hmm... what's heavy gcc load?
>
> make -j25 with 256 MB RAM.
>
> My X server is reniced at -1; but reniced X to -10 and it didn't helped;
> -j15 was better (less swapping) but still I saw various mp3 & mouse skips.
And this worked good with Con's scheduler?
Try both schedulers on the same base (test4), and see if you see similair
differences.
I doubt it's the scheduler that's causing this problem. Once you get into
swap like that, the scheduler shouldn't affect it too much...
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-04 18:23 ` 2.6.0-test4-mm5 Diego Calleja García
2003-09-04 19:08 ` 2.6.0-test4-mm5 Mike Fedyk
@ 2003-09-05 15:36 ` Martin Schlemmer
2003-09-05 16:17 ` 2.6.0-test4-mm5 Nick Piggin
1 sibling, 1 reply; 36+ messages in thread
From: Martin Schlemmer @ 2003-09-05 15:36 UTC (permalink / raw)
To: Diego Calleja García; +Cc: Nick Piggin, akpm, LKML
On Thu, 2003-09-04 at 20:23, Diego Calleja García wrote:
> El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <piggin@cyberone.com.au> escribió:
>
> > Hmm... what's heavy gcc load?
>
> make -j25 with 256 MB RAM.
>
> My X server is reniced at -1; but reniced X to -10 and it didn't helped;
> -j15 was better (less swapping) but still I saw various mp3 & mouse skips.
> -
Without trying to be insulting, don't you think that you might
be expecting too much ? I have a P4-2.4C (HT) on a i785 board
with 1GB DDR400 memory running dual channel, and if I run two
or three compile jobs at -j12 (more for testing Nick/Con's stuff,
usually use -j[46] and never really more than 2 of 3 of them), I
do not expect everything to be blazing fast. Yes, while it is
not swapping (rare if ever do swap), I do expect xmms not to
skip, I do not expect the mouse to jerk, and yes I do expect
changing desktops to be fairly smooth and responsive. I do not
however expect apps to still start with the same speed, or doing
the "window wiggle thing" to still be 100% smooth.
Nick's stuff with X reniced to -10 do fix the "window wiggle"
issue as far as I am concerned, as it is relative smooth (not
croaking like in vanilla), although not 100% as great as Con's,
but then Nick's finish the two make jobs at -j12 faster than
Con's stuff, and fairly close to vanilla (yes not 100% scientific),
and that is what I expect, even though it is a fairly ok machine.
Point I want to make, is that yes, for desktop you want you xmms
to not skip, you window switching to be ok while compiling a new
kernel at make -j[246], but come on, this is like expecting a
mini to out drag a F1 car because you fitted it with a turbo.
Especially when you start to swap heavily, you cannot really
expect the system to be responsive, especially when it is something
that needs to access memory that is swapped, or need to come out
of free swap, or that need to access the disk.
Con/Nick do need feedback, but really, expecting the scheduler to
be nice while your disk/memory is thrashing and whatever also need
a slice of that pie. Can we try to keep it real ?
Thanks,
--
Martin Schlemmer
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-05 15:36 ` 2.6.0-test4-mm5 Martin Schlemmer
@ 2003-09-05 16:17 ` Nick Piggin
2003-09-05 18:05 ` 2.6.0-test4-mm5 Diego Calleja García
0 siblings, 1 reply; 36+ messages in thread
From: Nick Piggin @ 2003-09-05 16:17 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: Diego Calleja García, akpm, LKML
Martin Schlemmer wrote:
>On Thu, 2003-09-04 at 20:23, Diego Calleja García wrote:
>
>>El Thu, 04 Sep 2003 11:32:49 +1000 Nick Piggin <piggin@cyberone.com.au> escribió:
>>
>>
>>>Hmm... what's heavy gcc load?
>>>
>>make -j25 with 256 MB RAM.
>>
>>My X server is reniced at -1; but reniced X to -10 and it didn't helped;
>>-j15 was better (less swapping) but still I saw various mp3 & mouse skips.
>>-
>>
>
>Without trying to be insulting, don't you think that you might
>be expecting too much ? I have a P4-2.4C (HT) on a i785 board
>with 1GB DDR400 memory running dual channel, and if I run two
>or three compile jobs at -j12 (more for testing Nick/Con's stuff,
>usually use -j[46] and never really more than 2 of 3 of them), I
>
I think Martin is right here. I don't know what would be a good reason
for wanting X to work nicely with a make -j25 running. X typically
needs at least 75% CPU on my box to be nicely interactive when moving
a window or scrolling something complex. This gives only 1% to each
cc1.
I am still working on my scheduler. I've removed backboost. It is
hypocritical of me to worry about complexity or difficult traceability
of say Con's implementation when backboost is probably "worse" than
anything he has ;)
So I've found I'm getting more consistent behaviour, but it is now
very dependant on nice to get X running well under load. I'm
concentrating on getting it working well with make -j <= 6.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-05 16:17 ` 2.6.0-test4-mm5 Nick Piggin
@ 2003-09-05 18:05 ` Diego Calleja García
0 siblings, 0 replies; 36+ messages in thread
From: Diego Calleja García @ 2003-09-05 18:05 UTC (permalink / raw)
To: Nick Piggin; +Cc: azarah, akpm, linux-kernel
El Sat, 06 Sep 2003 02:17:22 +1000 Nick Piggin <piggin@cyberone.com.au> escribió:
[chaging email to avoid smart spam detectors]
> I think Martin is right here. I don't know what would be a good reason
> for wanting X to work nicely with a make -j25 running. X typically
> needs at least 75% CPU on my box to be nicely interactive when moving
> a window or scrolling something complex. This gives only 1% to each
> cc1.
I know; obiously it has not sense to ask that people makes -j25
smooth here; there's no way of doing that (with gcc 3.x :)
I just pointed out that -mm4 was a bit better under that load, specially
mp3 skips.
> So I've found I'm getting more consistent behaviour, but it is now
> very dependant on nice to get X running well under load. I'm
> concentrating on getting it working well with make -j <= 6.
I just hope 2.6 is shipped with a "decent" scheduler. Mp3 players are
probably the most important apps nowadays :P
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-03 23:08 ` 2.6.0-test4-mm5 Diego Calleja García
2003-09-04 1:32 ` 2.6.0-test4-mm5 Nick Piggin
@ 2003-09-04 2:04 ` Mike Fedyk
2003-09-04 3:10 ` 2.6.0-test4-mm5 Nick Piggin
1 sibling, 1 reply; 36+ messages in thread
From: Mike Fedyk @ 2003-09-04 2:04 UTC (permalink / raw)
To: Diego Calleja Garc?a; +Cc: Andrew Morton, linux-kernel
On Thu, Sep 04, 2003 at 01:08:52AM +0200, Diego Calleja Garc?a wrote:
> El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <akpm@osdl.org> escribi?:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
> >
> > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > in evaluating the stability, efficacy and relative performance of Nick's
> > work.
> >
> > We're looking for feedback on the subjective behaviour and on the usual
> > server benchmarks please.
>
>
> I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
> skips that didn't happened before, big pauses in X...gcc starves anything else.
> -mm4 was better there.
Can you put your Xserver back to nice -10, and try again?
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-04 2:04 ` 2.6.0-test4-mm5 Mike Fedyk
@ 2003-09-04 3:10 ` Nick Piggin
0 siblings, 0 replies; 36+ messages in thread
From: Nick Piggin @ 2003-09-04 3:10 UTC (permalink / raw)
To: Mike Fedyk; +Cc: Diego Calleja Garc?a, Andrew Morton, linux-kernel
Mike Fedyk wrote:
>On Thu, Sep 04, 2003 at 01:08:52AM +0200, Diego Calleja Garc?a wrote:
>
>>El Tue, 2 Sep 2003 23:18:12 -0700 Andrew Morton <akpm@osdl.org> escribi?:
>>
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>>>
>>>. Dropped out Con's CPU scheduler work, added Nick's. This is to help us
>>> in evaluating the stability, efficacy and relative performance of Nick's
>>> work.
>>>
>>> We're looking for feedback on the subjective behaviour and on the usual
>>> server benchmarks please.
>>>
>>
>>I must say that this one doesn't feel nice under heavy gcc load. Huge mp3
>>skips that didn't happened before, big pauses in X...gcc starves anything else.
>>-mm4 was better there.
>>
>
>Can you put your Xserver back to nice -10, and try again?
>
This would help X, but regardless mp3 playing should not skip. I think its
giving newly forked children much too high a priority. Basically new
children
can't get less than 50% sleep time, which is stupid on my behalf because a
program which continually forks children that do a little bit of work then
exit would basically be at 50% sleep time when it should be at or close
to 0.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-03 6:18 2.6.0-test4-mm5 Andrew Morton
` (3 preceding siblings ...)
2003-09-03 23:08 ` 2.6.0-test4-mm5 Diego Calleja García
@ 2003-09-04 1:30 ` Bill Huey
2003-09-04 3:12 ` 2.6.0-test4-mm5 Chris Wright
2003-09-04 14:29 ` 2.6.0-test4-mm5 Bruno T. Moura
2003-09-07 10:08 ` 2.6.0-test4-mm5 and below: Wine and XMMS problems Adrian Bunk
6 siblings, 1 reply; 36+ messages in thread
From: Bill Huey @ 2003-09-04 1:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Bill Huey (hui)
On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
CHK include/linux/compile.h
CC drivers/acpi/pci_link.o
drivers/acpi/pci_link.c: In function `acpi_pci_link_try_get_current':
drivers/acpi/pci_link.c:290: error: `_dbg' undeclared (first use in this function)
drivers/acpi/pci_link.c:290: error: (Each undeclared identifier is reported only once
drivers/acpi/pci_link.c:290: error: for each function it appears in.)
make[2]: *** [drivers/acpi/pci_link.o] Error 1
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2
------------------------------------------------------------------------------------------
bill
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5
2003-09-04 1:30 ` 2.6.0-test4-mm5 Bill Huey
@ 2003-09-04 3:12 ` Chris Wright
0 siblings, 0 replies; 36+ messages in thread
From: Chris Wright @ 2003-09-04 3:12 UTC (permalink / raw)
To: Bill Huey; +Cc: Andrew Morton, linux-kernel
* Bill Huey (billh@gnuppy.monkey.org) wrote:
> On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>
> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
> CHK include/linux/compile.h
> CC drivers/acpi/pci_link.o
> drivers/acpi/pci_link.c: In function `acpi_pci_link_try_get_current':
> drivers/acpi/pci_link.c:290: error: `_dbg' undeclared (first use in this function)
> drivers/acpi/pci_link.c:290: error: (Each undeclared identifier is reported only once
> drivers/acpi/pci_link.c:290: error: for each function it appears in.)
> make[2]: *** [drivers/acpi/pci_link.o] Error 1
> make[1]: *** [drivers/acpi] Error 2
> make: *** [drivers] Error 2
try the patch below.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
--- drivers/acpi/pci_link.c.try Wed Sep 3 15:06:33 2003
+++ drivers/acpi/pci_link.c Wed Sep 3 15:07:22 2003
@@ -285,6 +285,8 @@ acpi_pci_link_try_get_current (
{
int result;
+ ACPI_FUNCTION_TRACE("acpi_pci_link_try_get_current");
+
result = acpi_pci_link_get_current(link);
if (result && link->irq.active) {
return_VALUE(result);
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5
2003-09-03 6:18 2.6.0-test4-mm5 Andrew Morton
` (4 preceding siblings ...)
2003-09-04 1:30 ` 2.6.0-test4-mm5 Bill Huey
@ 2003-09-04 14:29 ` Bruno T. Moura
2003-09-04 14:44 ` 2.6.0-test4-mm5 Bruno T. Moura
2003-09-04 20:29 ` 2.6.0-test4-mm5 Alan Cox
2003-09-07 10:08 ` 2.6.0-test4-mm5 and below: Wine and XMMS problems Adrian Bunk
6 siblings, 2 replies; 36+ messages in thread
From: Bruno T. Moura @ 2003-09-04 14:29 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
On Tue, 2 Sep 2003 23:18:12 -0700
Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
>
> . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> in evaluating the stability, efficacy and relative performance of Nick's
> work.
>
[ snip. ]
Getting this one when setting dma on a barracuda SATA ST380013AS, i875 chipset.
Sep 4 09:53:26 pyro kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
Sep 4 09:53:26 pyro kernel: hde: channel busy
Sep 4 09:53:26 pyro kernel: hde: Speed warnings UDMA 3/4/5 is not functional.
Sep 4 09:53:26 pyro kernel: hde: dma_timer_expiry: dma status == 0x20
Sep 4 09:53:26 pyro kernel: hde: DMA timeout retry
Sep 4 09:53:26 pyro kernel: hde: timeout waiting for DMA
Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
Sep 4 09:53:26 pyro kernel:
Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
Sep 4 09:53:26 pyro kernel:
Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5
2003-09-04 14:29 ` 2.6.0-test4-mm5 Bruno T. Moura
@ 2003-09-04 14:44 ` Bruno T. Moura
2003-09-04 20:29 ` 2.6.0-test4-mm5 Alan Cox
1 sibling, 0 replies; 36+ messages in thread
From: Bruno T. Moura @ 2003-09-04 14:44 UTC (permalink / raw)
Cc: Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
On Thu, 4 Sep 2003 10:29:18 -0400
"Bruno T. Moura" <bruno.tavares@terra.com.br> wrote:
> On Tue, 2 Sep 2003 23:18:12 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test4/2.6.0-test4-mm5/
> >
> > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > in evaluating the stability, efficacy and relative performance of Nick's
> > work.
> >
> [ snip. ]
>
> Getting this one when setting dma on a barracuda SATA ST380013AS, i875 chipset.
>
> Sep 4 09:53:26 pyro kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
> Sep 4 09:53:26 pyro kernel: hde: channel busy
> Sep 4 09:53:26 pyro kernel: hde: Speed warnings UDMA 3/4/5 is not functional.
> Sep 4 09:53:26 pyro kernel: hde: dma_timer_expiry: dma status == 0x20
> Sep 4 09:53:26 pyro kernel: hde: DMA timeout retry
> Sep 4 09:53:26 pyro kernel: hde: timeout waiting for DMA
> Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
> Sep 4 09:53:26 pyro kernel:
> Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
> Sep 4 09:53:26 pyro kernel: hde: status timeout: status=0xd0 { Busy }
> Sep 4 09:53:26 pyro kernel:
> Sep 4 09:53:26 pyro kernel: hde: drive not ready for command
>
forgot this log part :
Sep 4 09:53:26 pyro kernel: ide2: reset: success
Sep 4 09:53:26 pyro kernel: hde: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
Sep 4 09:53:26 pyro kernel: hde: task_no_data_intr: error=0x04 { DriveStatusError }
Sep 4 09:53:26 pyro kernel: blk: queue 41d72600, I/O limit 4095Mb (mask 0xffffffff)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5
2003-09-04 14:29 ` 2.6.0-test4-mm5 Bruno T. Moura
2003-09-04 14:44 ` 2.6.0-test4-mm5 Bruno T. Moura
@ 2003-09-04 20:29 ` Alan Cox
1 sibling, 0 replies; 36+ messages in thread
From: Alan Cox @ 2003-09-04 20:29 UTC (permalink / raw)
To: Bruno T. Moura; +Cc: Andrew Morton, Linux Kernel Mailing List
On Iau, 2003-09-04 at 15:29, Bruno T. Moura wrote:
> Sep 4 09:53:26 pyro kernel: hde: Speed warnings UDMA 3/4/5 is not functional.
> Sep 4 09:53:26 pyro kernel: hde: dma_timer_expiry: dma status == 0x20
> Sep 4 09:53:26 pyro kernel: hde: DMA timeout retry
SATA mode on the ICH5 really wants to be driven by Jeff Garziks libata
SATA drivers not the ide layer code. The IDE code doesnt currently know
about cable detect not being valid on the SATA ports.
^ permalink raw reply [flat|nested] 36+ messages in thread
* 2.6.0-test4-mm5 and below: Wine and XMMS problems
2003-09-03 6:18 2.6.0-test4-mm5 Andrew Morton
` (5 preceding siblings ...)
2003-09-04 14:29 ` 2.6.0-test4-mm5 Bruno T. Moura
@ 2003-09-07 10:08 ` Adrian Bunk
2003-09-07 10:39 ` Nick Piggin
2003-09-07 12:18 ` Con Kolivas
6 siblings, 2 replies; 36+ messages in thread
From: Adrian Bunk @ 2003-09-07 10:08 UTC (permalink / raw)
To: Andrew Morton, Nick Piggin, Con Kolivas; +Cc: linux-kernel, linux-mm
On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
>...
> . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> in evaluating the stability, efficacy and relative performance of Nick's
> work.
>
> We're looking for feedback on the subjective behaviour and on the usual
> server benchmarks please.
>...
Short story:
I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
problems
Long story:
System:
K6-2 @ 500 MHz
128 MB RAM
1 GB swap
Debian unstable
Workload:
XFree86
FVWM
XMMS
Wine running "Master of Orion 2" (a round based space strategy game)
With 2.4 kernels and 2.5.72 everything works fine.
With 2.6.0-test? and 2.6.0-test?-mm? kernels up to 2.6.0-test4-mm4 the
XMMS sound sometimes skips or sounds slow (like when wou manually retard
a record). That's much more awful than skips.
RAM usage is low, even after a "swapoff -a" at about half of my RAM
would be enough.
The problems might be related to the fact that after I start Wine three
wine.bin processes run and each of them tries to get as much CPU time as
possible.
It might be part of the problem that although Wine is the interactive
task a working XMMS is subjectively more important.
With 2.6.0-test4-mm5 these problems don't occur. Instead, Wine feels
slow. I couldn;t test it much since after the first fast mouse movement
the X mouse cursor has lost the mouse cursor of the game (this might be
a bug in Wine, but it doesnt occur with other kernels).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5 and below: Wine and XMMS problems
2003-09-07 10:08 ` 2.6.0-test4-mm5 and below: Wine and XMMS problems Adrian Bunk
@ 2003-09-07 10:39 ` Nick Piggin
2003-09-08 23:08 ` Adrian Bunk
2003-09-07 12:18 ` Con Kolivas
1 sibling, 1 reply; 36+ messages in thread
From: Nick Piggin @ 2003-09-07 10:39 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Con Kolivas, linux-kernel, linux-mm
Adrian Bunk wrote:
>On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
>
>>...
>>. Dropped out Con's CPU scheduler work, added Nick's. This is to help us
>> in evaluating the stability, efficacy and relative performance of Nick's
>> work.
>>
>> We're looking for feedback on the subjective behaviour and on the usual
>> server benchmarks please.
>>...
>>
>
>Short story:
>
>I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
>problems
>
>
>Long story:
>
>System:
>K6-2 @ 500 MHz
>128 MB RAM
>1 GB swap
>Debian unstable
>
>Workload:
>XFree86
>FVWM
>XMMS
>Wine running "Master of Orion 2" (a round based space strategy game)
>
>With 2.4 kernels and 2.5.72 everything works fine.
>
>With 2.6.0-test? and 2.6.0-test?-mm? kernels up to 2.6.0-test4-mm4 the
>XMMS sound sometimes skips or sounds slow (like when wou manually retard
>a record). That's much more awful than skips.
>
>RAM usage is low, even after a "swapoff -a" at about half of my RAM
>would be enough.
>
>The problems might be related to the fact that after I start Wine three
>wine.bin processes run and each of them tries to get as much CPU time as
>possible.
>
>It might be part of the problem that although Wine is the interactive
>task a working XMMS is subjectively more important.
>
>With 2.6.0-test4-mm5 these problems don't occur. Instead, Wine feels
>slow. I couldn;t test it much since after the first fast mouse movement
>the X mouse cursor has lost the mouse cursor of the game (this might be
>a bug in Wine, but it doesnt occur with other kernels).
>
>cu
>Adrian
>
Hi Adrian,
It would be great if you could test the latest mm kernel (mm6 as of now
I think), which has Con's latest stuff in it. You could also test my
newest scheduler patch. Thanks for the feedback.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5 and below: Wine and XMMS problems
2003-09-07 10:39 ` Nick Piggin
@ 2003-09-08 23:08 ` Adrian Bunk
2003-09-10 22:03 ` Adrian Bunk
0 siblings, 1 reply; 36+ messages in thread
From: Adrian Bunk @ 2003-09-08 23:08 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, Con Kolivas, linux-kernel, linux-mm
On Sun, Sep 07, 2003 at 08:39:14PM +1000, Nick Piggin wrote:
>
> Hi Adrian,
Hi Nick,
> It would be great if you could test the latest mm kernel (mm6 as of now
> I think), which has Con's latest stuff in it. You could also test my
> newest scheduler patch. Thanks for the feedback.
I didn't check -mm6 (I had a different problem with -mm6 and not that
much time).
I tried plain test4 with your sched-rollup-v14 and I got these awful
slower sound like when wou manually retard a record.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5 and below: Wine and XMMS problems
2003-09-08 23:08 ` Adrian Bunk
@ 2003-09-10 22:03 ` Adrian Bunk
0 siblings, 0 replies; 36+ messages in thread
From: Adrian Bunk @ 2003-09-10 22:03 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, Con Kolivas, linux-kernel, linux-mm
On Tue, Sep 09, 2003 at 01:08:20AM +0200, Adrian Bunk wrote:
> On Sun, Sep 07, 2003 at 08:39:14PM +1000, Nick Piggin wrote:
> >
> > Hi Adrian,
>
> Hi Nick,
>
> > It would be great if you could test the latest mm kernel (mm6 as of now
> > I think), which has Con's latest stuff in it. You could also test my
> > newest scheduler patch. Thanks for the feedback.
>
> I didn't check -mm6 (I had a different problem with -mm6 and not that
> much time).
>
> I tried plain test4 with your sched-rollup-v14 and I got these awful
> slower sound like when wou manually retard a record.
More data:
I tried test5 and test5-mm1.
Both produced this awful slower sound like when wou manually retard a
record, although my subjective impression was that it happens fewer than
with test4 with your sched-rollup-v14.
2.5.72 is still better than all recent kernels I've tested... :-(
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: 2.6.0-test4-mm5 and below: Wine and XMMS problems
2003-09-07 10:08 ` 2.6.0-test4-mm5 and below: Wine and XMMS problems Adrian Bunk
2003-09-07 10:39 ` Nick Piggin
@ 2003-09-07 12:18 ` Con Kolivas
2003-09-07 19:04 ` Adrian Bunk
1 sibling, 1 reply; 36+ messages in thread
From: Con Kolivas @ 2003-09-07 12:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
On Sun, 7 Sep 2003 20:08, Adrian Bunk wrote:
> On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> >...
> > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > in evaluating the stability, efficacy and relative performance of
> > Nick's work.
> >
> > We're looking for feedback on the subjective behaviour and on the usual
> > server benchmarks please.
> >...
>
> Short story:
>
> I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
> problems
What's your X and xmms nice values? Many X servers are reniced to -10 and some
shells spawn new apps at nice 5. After that the most common thing I find in
reports are upgrades to newer kernels losing hard disk dma at some stage (due
to config changes/movements) and it not being noticed.
Con
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: 2.6.0-test4-mm5 and below: Wine and XMMS problems
2003-09-07 12:18 ` Con Kolivas
@ 2003-09-07 19:04 ` Adrian Bunk
0 siblings, 0 replies; 36+ messages in thread
From: Adrian Bunk @ 2003-09-07 19:04 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel
On Sun, Sep 07, 2003 at 10:18:27PM +1000, Con Kolivas wrote:
> On Sun, 7 Sep 2003 20:08, Adrian Bunk wrote:
> > On Tue, Sep 02, 2003 at 11:18:12PM -0700, Andrew Morton wrote:
> > >...
> > > . Dropped out Con's CPU scheduler work, added Nick's. This is to help us
> > > in evaluating the stability, efficacy and relative performance of
> > > Nick's work.
> > >
> > > We're looking for feedback on the subjective behaviour and on the usual
> > > server benchmarks please.
> > >...
> >
> > Short story:
> >
> > I'm still using 2.5.72, all of the 2.6.0-test?{,-mm?} kernels have
> > problems
>
> What's your X and xmms nice values? Many X servers are reniced to -10 and some
They have both nice value 0.
> shells spawn new apps at nice 5. After that the most common thing I find in
> reports are upgrades to newer kernels losing hard disk dma at some stage (due
> to config changes/movements) and it not being noticed.
DMA is wrking without problems.
> Con
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 36+ messages in thread