2.4.19-preX: What we really need: -AA patches finally in the tree
<massive snippage>
Quoted 2 lines
That sounds very nice, but in practice it means it would never happen, and you know it.
Excuse me...I've been a lurker and sometimes tester since 2.0.*. I've been working my way through man (3) to learn enough to submit a coherent patch and I don't appreciate you telling me I can't do it. I've searched your submissions to LKML and all I see are opinions, ie == !code_submitted.
Quoted 2 lines
This process could take six months to a year, after which we can start the process with the scheduler.
Who exactly are "we" anyway? I know it's not me because I haven't contributed DIDDLY for code just yet.
Just a note: CD Burner, Parport/ECP/EPP/Zip broken with 2.4.17, will try 2.4.19. 2.4.18 too ugly to test.
Apologies to the kernel-list, I usually try to limit my noise...
Signature · 4 lines
Dart "I have studied many philosophers and many cats. The wisdom of cats is infinitely superior." -- Hippolyte Taine
Quoted 10 lines · dart
<massive snippage>
Quoted 2 lines
That sounds very nice, but in practice it means it would never happen, and you know it.
Excuse me...I've been a lurker and sometimes tester since 2.0.*. I've been working my way through man (3) to learn enough to submit a coherent patch and I don't appreciate you telling me I can't do it. I've searched your submissions to LKML and all I see are opinions, ie == !code_submitted.
Correct, after sending in patches to people who didn't bother to ack
them (except Alan), I got the message and stopped bothering people. Since I've been writing software for a living longer than there's been a Linux, I always provide a description of the bug with a test if needed. Somewhere around 2.1 I let it ride, and I haven't even followed lkml until about six months ago.
Quoted 5 lines
Quoted 2 lines
This process could take six months to a year, after which we can start the process with the scheduler.
Who exactly are "we" anyway? I know it's not me because I haven't contributed DIDDLY for code just yet.
People who would like to see better performance in *this* stable kernel,
not 2.6 in two years (look at the jump from stable 2.2 to whatever you think is stable in 2.4 and tell me your estimate).
I won't bring it up again, I'd love to think Rik, Alan and Ingo will
keep working on performance patches for 2.4, but I wouldn't bet on it.
Quoted 2 lines
Just a note: CD Burner, Parport/ECP/EPP/Zip broken with 2.4.17, will try 2.4.19. 2.4.18 too ugly to test.
I have no idea if this is related to the fix posted recently WRT PL/IP,
after I commented that I was looking at the code to see why it changed someone asked if 19-pre2 didn't work. I admit I only looked to see if the change which broke it was reverted, but it looks as if some work has been done in -pre2, might be worth a try. I'm going to build pre2-ac2 and mjc for some laptop benchmarks, I'll turn on ZIP support and try my old unit (the original protocol). I'll try to report back on that in the next day or so.
If I brought my laplink cable with me I might give PL/IP a try this
week, otherwise I'll bring it next week, the weekend is being better spent on ECAC hockey playoffs ;-)
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 2 lines
I won't bring it up again, I'd love to think Rik, Alan and Ingo will
keep working on performance patches for 2.4, but I wouldn't bet on it.
I certainly will work on collating them - over time it will get less and less of a win. A lot of the now very visible ones are really hard to fix in 2.4 and will be 2.5 things (like block). And when you fix block you'll find the next one and so on forever
Quoted 4 lines
done in -pre2, might be worth a try. I'm going to build pre2-ac2 and mjc for some laptop benchmarks, I'll turn on ZIP support and try my old unit (the original protocol). I'll try to report back on that in the next day or so.
Im running both 2.4.18/19pre2 on laptops. PLIP still doesnt work but at least I think I now understand why. If you want to hack on plip ping Tim Waugh <[email protected]> he's definitely as far from the Al Viro end of polite computing as you can get and can probably tell you what bits you need to tweak
Quoted 8 lines · Alan Cox
Quoted 3 lines
I won't bring it up again, I'd love to think Rik, Alan and Ingo will
keep working on performance patches for 2.4, but I wouldn't bet on it.I certainly will work on collating them - over time it will get less and less of a win. A lot of the now very visible ones are really hard to fix in 2.4 and will be 2.5 things (like block). And when you fix block you'll find the next one and so on forever
I'd love to see some performance patches. I've been watching my quake "timerefreshes" drop since 2.2. I've been using Ingo's scheduler patches on 2.4.17 with vast improvements in "smoothness" with what seems like an occasional block on big writes. I also tried 2.4.19-pre2-ac2(with scheduler merged), in that case the smoothness wasn't quite so apparent even with X niced to -10. There were also a lot of sound skips that didn't happen with 2.4.17/sched-K3. I attributed those to the renicing of X to smooth out the mouse.
Quoted 11 lines
Quoted 5 lines
done in -pre2, might be worth a try. I'm going to build pre2-ac2 and mjc for some laptop benchmarks, I'll turn on ZIP support and try my old unit (the original protocol). I'll try to report back on that in the next day or so.
Im running both 2.4.18/19pre2 on laptops. PLIP still doesnt work but at least I think I now understand why. If you want to hack on plip ping Tim Waugh <[email protected]> he's definitely as far from the Al Viro end of polite computing as you can get and can probably tell you what bits you need to tweak
As I indicated to Bill in a private mail the parport code has *never* properly detected my ECP/EPP although my zipdrive(IMM) DOES work. It's in compatibility mode and horribly slow. I've been futzing with probe.c with no luck. More info available on request. I believe ECP is supposed to work with this thing at around a theoretical 1.2 MB/sec. This is an Intel GX chipset with an Award v6.0 bios, Winbond 83977TF 2meg bios chip.
parport info:
parport0: PC-style at 0x378 (0x778), irq 7<7>0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 160x378: readIntrThreshold is 160x378: PWord is 8 bits0x378: Interrupts are ISA-Pulses0x378: ECP port cfgA=0x10 cfgB=0x480x378: ECP settings irq=7 dma=<none or set by other means> , dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
parport0: device reported incorrect length field (61, should be 62) parport0 (addr 0): SCSI adapter, IMG VP1
imm: Version 2.05 (for Linux 2.4.0)
imm: Found device at ID 6, Attempting to use EPP 32 bit
imm: Found device at ID 6, Attempting to use PS/2
imm: Communication established at 0x378 with ID 6 using PS/2 scsi1 : Iomega VPI2 (imm) interface
Vendor: IOMEGA Model: ZIP 100 Rev: P.05
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi1, channel 0, id 6, lun 0 SCSI device sda: 196608 512-byte hdwr sectors (101 MB)
sda: Write Protect is off
sda: sda4
invalidate: busy buffer
invalidate: busy buffer
Hdparm:/dev/sda4:
Timing buffer-cache reads: 128 MB in 1.01 seconds =126.73 MB/sec
Timing buffered disk reads: 64 MB in 438.02 seconds =149.62 kB/sec
Bill isn't the only one that does "interesting things with computers"....:=)
BTW Alan I've given up on my "special" epic100(broken/workaround since 2.4.4..completely dead at 2.4.10), we've talked about this before. I see fixes in the latest -pre patches but I just replaced it a week or two ago and am tired of futzing with it right now. I'll try it again sometime if anyone is interested.
Signature · 4 lines
James M. aka "Dart" "I have studied many philosophers and many cats. The wisdom of cats is infinitely superior." -- Hippolyte Taine
I wouldn't be surprised if the next RH kernel included O(1) and the low-latency stuff. If it doesn't already. 2.4.18+O1+LOWLAT works great for me in production and seems like the best overall solution while we wait for 2.4.19+aa, and then possibly 2.x+rmap farther out.
FWIW, I completely agree with Alan. 2.4 will keep moving, but it's a stable release now and the rate has to be lower and more calculated. 2.4 already made its big improvements over 2.2, and we shouldn't break further from the concept of releases to increase the rate of 2.4 change. Entropy is, by definition, not stable, even if it's "good stuff" we're adding. All IMHO.
Signature · 2 lines
Ken. [email protected]
On Tue, Mar 05, 2002 at 07:45:45PM -0600, James M. wrote:
| Alan Cox wrote: | > | > > I won't bring it up again, I'd love to think Rik, Alan and Ingo will | > > keep working on performance patches for 2.4, but I wouldn't bet on it. | > | > I certainly will work on collating them - over time it will get less and | > less of a win. A lot of the now very visible ones are really hard to fix in 2.4 | > and will be 2.5 things (like block). And when you fix block you'll find the | > next one and so on forever | | I'd love to see some performance patches. I've been watching my quake | "timerefreshes" drop since 2.2. I've been using Ingo's scheduler patches | on 2.4.17 with vast improvements in "smoothness" with what seems like an | occasional block on big writes. I also tried 2.4.19-pre2-ac2(with | scheduler merged), in that case the smoothness wasn't quite so apparent | even with X niced to -10. There were also a lot of sound skips that | didn't happen with 2.4.17/sched-K3. I attributed those to the renicing | of X to smooth out the mouse. | | > | > > done in -pre2, might be worth a try. I'm going to build pre2-ac2 and mjc | > > for some laptop benchmarks, I'll turn on ZIP support and try my old unit | > > (the original protocol). I'll try to report back on that in the next day | > > or so. | > | > Im running both 2.4.18/19pre2 on laptops. PLIP still doesnt work but at | > least I think I now understand why. If you want to hack on plip ping | > Tim Waugh <[email protected]> he's definitely as far from the Al Viro end | > of polite computing as you can get and can probably tell you what bits you | > need to tweak | | As I indicated to Bill in a private mail the parport code has *never* | properly detected my ECP/EPP although my zipdrive(IMM) DOES work. It's | in compatibility mode and horribly slow. I've been futzing with probe.c | with no luck. More info available on request. I believe ECP is supposed | to work with this thing at around a theoretical 1.2 MB/sec. This is an | Intel GX chipset with an Award v6.0 bios, Winbond 83977TF 2meg bios | chip. | | parport info: | parport0: PC-style at 0x378 (0x778), irq 7<7>0x378: FIFO is 16 bytes | 0x378: writeIntrThreshold is 16 | 0x378: readIntrThreshold is 16 | 0x378: PWord is 8 bits | 0x378: Interrupts are ISA-Pulses | 0x378: ECP port cfgA=0x10 cfgB=0x48 | 0x378: ECP settings irq=7 dma=<none or set by other means> | , dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] | parport0: device reported incorrect length field (61, should be 62) | parport0 (addr 0): SCSI adapter, IMG VP1 | imm: Version 2.05 (for Linux 2.4.0) | imm: Found device at ID 6, Attempting to use EPP 32 bit | imm: Found device at ID 6, Attempting to use PS/2 | imm: Communication established at 0x378 with ID 6 using PS/2 | scsi1 : Iomega VPI2 (imm) interface | Vendor: IOMEGA Model: ZIP 100 Rev: P.05 | Type: Direct-Access ANSI SCSI revision: 02 | Attached scsi removable disk sda at scsi1, channel 0, id 6, lun 0 | SCSI device sda: 196608 512-byte hdwr sectors (101 MB) | sda: Write Protect is off | sda: sda4 | invalidate: busy buffer | invalidate: busy buffer | | Hdparm: | /dev/sda4: | Timing buffer-cache reads: 128 MB in 1.01 seconds =126.73 MB/sec | Timing buffered disk reads: 64 MB in 438.02 seconds =149.62 kB/sec | | Bill isn't the only one that does "interesting things with | computers"....:=) | | BTW Alan I've given up on my "special" epic100(broken/workaround since | 2.4.4..completely dead at 2.4.10), we've talked about this before. I see | fixes in the latest -pre patches but I just replaced it a week or two | ago and am tired of futzing with it right now. I'll try it again | sometime if anyone is interested. | | -- | James M. aka "Dart" | | "I have studied many philosophers and many cats. | The wisdom of cats is infinitely superior." -- Hippolyte Taine | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to [email protected] | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · James M.
Quoted 7 lines · Alan Cox
Quoted 2 lines
I won't bring it up again, I'd love to think Rik, Alan and Ingo will
keep working on performance patches for 2.4, but I wouldn't bet on it.I certainly will work on collating them - over time it will get less and less of a win. A lot of the now very visible ones are really hard to fix in 2.4 and will be 2.5 things (like block). And when you fix block you'll find the next one and so on forever
Quoted 8 lines
I'd love to see some performance patches. I've been watching my quake "timerefreshes" drop since 2.2. I've been using Ingo's scheduler patches on 2.4.17 with vast improvements in "smoothness" with what seems like an occasional block on big writes. I also tried 2.4.19-pre2-ac2(with scheduler merged), in that case the smoothness wasn't quite so apparent even with X niced to -10. There were also a lot of sound skips that didn't happen with 2.4.17/sched-K3. I attributed those to the renicing of X to smooth out the mouse.
I can really recommend 2.4.18-pre9-mjc2; it's _much_ better than 2.4.18-pre8-mjc (I guess that's the difference between K2 and K3) and gives great interactive feel. I had it running continously for almost 20 days now and I've beaten it like hell, with vmware, wine, heavily threaded java apps, etc.. While doing really crazy things like "make -j 200" on my lowend athlon with 640MB RAM, the system remains 100% responsive, and this with a load well over 200 and more than 1000 processes!!
Where these "performance" enhancements are really getting invaluable, is when you do things like opening 1000 mp3 files in konqueror thinking you had "allow multiple instances" disabled in xmms... ;
the stock 2.4 kernel just falls flat in such a situation, not even giving you the possibility to switch to the console to type "killall xmms" :-) so all these "performance" patches (especially the scheduler of course) do have invaluable benefits even for normal users with UP systems, and are therefore, IMHO of course, worth being integrated into 2.4 mainline. cheers,
Yven
P.S: thanks for all the fantastic work :-)
Signature · 2 lines
Yven Johannes Leist - [email protected] http://www.leist.beldesign.de
Dear Ken Brownfield,
Once you wrote about "Re: 2.4.19-preX: What we really need: -AA patches finally in the tree":
KB> I wouldn't be surprised if the next RH kernel included O(1) and the
KB> low-latency stuff. If it doesn't already. 2.4.18+O1+LOWLAT works great KB> for me in production and seems like the best overall solution while we
KB> wait for 2.4.19+aa, and then possibly 2.x+rmap farther out.
Rawhide kernel 2.4.17 already has low latency patch applied.
Signature · 4 lines
Best regards, Leonid Mamtchenkov, RHCE System Administrator Francoudi & Stephanou Ltd.