Without them we do _NOT_ calm the flamewar against Linux's 2.4 VM.
Second, it is time for the outstanding ReiserFS patches.
If we are somewhat risky we put Ingo's GREAT O(1)-scheduler in, too.
Preemption is than another story.
Thank you for any feedback in advance.
This not intended as a flamewar start.
-Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
While I agree that -aa (or -rmap -- something to rescue the VM) should
go in ASAP, applying O(1) is a little more questionable. I've been
applying O(1) for a while with great results, but it could be construed
as changing significantly the behavior of a stable kernel series. I
don't know if it does, but I can see it breaking certain apps or modules
that relied on previous behavior. Kind of like that parent vs. child
scheduling issue of a few months ago. But I could be all wet on that.
It should be in it's own release separate from other major changes at
least, IMHO, if the backport is desired by enough folk to outweigh the
largish change. And I definitely have VM _way_ higher up my personal
list. :)
--
Ken.
[email protected]
On Tue, Feb 26, 2002 at 01:35:18AM +0100, Dieter N?tzel wrote:
| Without them we do _NOT_ calm the flamewar against Linux's 2.4 VM.
| Second, it is time for the outstanding ReiserFS patches.
| If we are somewhat risky we put Ingo's GREAT O(1)-scheduler in, too.
| Preemption is than another story.
|
| Thank you for any feedback in advance.
| This not intended as a flamewar start.
|
| -Dieter
| --
| Dieter N?tzel
| Graduate Student, Computer Science
|
| University of Hamburg
| Department of Computer Science
| Ohome: Dieter.NuetzelOhamburg.de
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomoOvger.kernel.org
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
Ken Brownfield wrote:
>
> ...
> It should be in it's own release separate from other major changes at
> least, IMHO, if the backport is desired by enough folk to outweigh the
> largish change. And I definitely have VM _way_ higher up my personal
> list. :)
>
I intend to chunk up the -aa VM patch and feed it into 2.4.19-pre.
I think Andrea's OK with that. Just the VM and buffercache bits.
Something also needs to be done about block-highmem and pte-highmem.
It'll take some time - it needs to go in across several releases
so we can keep an eye on its effects, and there seem to be quite
a lot of little personal patchpiles banked up for 2.4.19.
-
Not to begin the flamewar, but no thanks. rmap-12f blows -aa away AFAIK
on this P200 w/ 64MB ram.
Sorry :-)
> Mon, 2002-02-25 at 19:35, Dieter N?tzel wrote:
> Without them we do _NOT_ calm the flamewar against Linux's 2.4 VM.
> Second, it is time for the outstanding ReiserFS patches.
> If we are somewhat risky we put Ingo's GREAT O(1)-scheduler in, too.
> Preemption is than another story.
>
> Thank you for any feedback in advance.
> This not intended as a flamewar start.
>
> -Dieter
> --
> Dieter N?tzel
> Graduate Student, Computer Science
>
> University of Hamburg
> Department of Computer Science
> @home: [email protected]
>
> -
> 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/
>
> While I agree that -aa (or -rmap -- something to rescue the VM) should
> go in ASAP, applying O(1) is a little more questionable. I've been
> applying O(1) for a while with great results, but it could be construed
I plan to put O(1) in the -ac tree to see how it works out
> that relied on previous behavior. Kind of like that parent vs. child
> scheduling issue of a few months ago. But I could be all wet on that.
For big boxes its fairly important to have O(1). For the new Intel Xeons
its very much more pressing because your box just doubled its notional
number of CPUs and the results with the old scheduler are deeply unfunny
> Not to begin the flamewar, but no thanks. rmap-12f blows -aa away AFAIK
> on this P200 w/ 64MB ram.
rmap still sucks on large systems though. I'd love to see rmap
in the main kernel, but it needs to get the scalability fixed first.
The main problem seems to be pagemap_lru_lock ... Rik & crew
know about this problem, but let's give them some time to fix it
before rmap gets put into mainline ....
Martin.
> rmap still sucks on large systems though. I'd love to see rmap
> in the main kernel, but it needs to get the scalability fixed first.
> The main problem seems to be pagemap_lru_lock ... Rik & crew
> know about this problem, but let's give them some time to fix it
> before rmap gets put into mainline ....
It needs to works with page tables in highmem too
On Mon, 25 Feb 2002, Martin J. Bligh wrote:
> > Not to begin the flamewar, but no thanks. rmap-12f blows -aa away AFAIK
> > on this P200 w/ 64MB ram.
>
> rmap still sucks on large systems though. I'd love to see rmap
> in the main kernel, but it needs to get the scalability fixed first.
> The main problem seems to be pagemap_lru_lock ... Rik & crew
> know about this problem, but let's give them some time to fix it
> before rmap gets put into mainline ....
This isn't very near on my TODO list though, I've got
the following big items coming up shortly:
rmap 13: O(1) page_launder <- working on it now
rmap 14: pte-highmem support
In addition to this I'm merging some small pieces of code
with both Linus and Marcelo.
Making the locking more scaleable wrt. the pagemap_lru_lock
could be either a simple change or a rework of the way the
VM does locking. I'm not sure which way to go...
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
> Making the locking more scaleable wrt. the pagemap_lru_lock
> could be either a simple change or a rework of the way the
> VM does locking. I'm not sure which way to go...
If the simple change works, it would be cool to see that as
a first step (I sent you a simplistic patch, but I'm not at all sure
it's correct). Breaking up that lock might expose something
else that people could work on in the meantime ....
M.
On February 26, 2002 02:32 am, Martin J. Bligh wrote:
> > Not to begin the flamewar, but no thanks. rmap-12f blows -aa away AFAIK
> > on this P200 w/ 64MB ram.
>
> rmap still sucks on large systems though.
But this is not a fundamental issue, it's implementation. Whereas non-rmap
will always suck on large systems, for fundamental reasons that are unrelated
to the quality of the implementation.
> I'd love to see rmap
> in the main kernel, but it needs to get the scalability fixed first.
Yes.
> The main problem seems to be pagemap_lru_lock ... Rik & crew
> know about this problem, but let's give them some time to fix it
> before rmap gets put into mainline ....
Yes, yes and yes.
--
Daniel
>> rmap still sucks on large systems though.
>
> But this is not a fundamental issue, it's implementation.
> Whereas non-rmap will always suck on large systems, for
> fundamental reasons that are unrelated to the quality of
> the implementation.
Absolutely ... it's just not quite finished yet. I'm
convinced it'll be a major win for everyone in the end,
I just squirm a little when I see people advocating it
going into the mainline right now.
M.
In article <[email protected]> you wrote:
> Without them we do _NOT_ calm the flamewar against Linux's 2.4 VM.
-aa VM is too big an uncommented - to get it into mainline someone needs
to feed it in chunks and back out obviously wrong hunks like reversing
bugfixes done in the mainline.
Other -aa parts are much saner and if no one else does it will feed big
parts to Marcelo.
> Second, it is time for the outstanding ReiserFS patches.
Maybe the reiserfs folks should submit them then?
> If we are somewhat risky we put Ingo's GREAT O(1)-scheduler in, too.
Kill source compatiblity for drivers -> no way.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Mon, Feb 25 2002, Andrew Morton wrote:
> Ken Brownfield wrote:
> >
> > ...
> > It should be in it's own release separate from other major changes at
> > least, IMHO, if the backport is desired by enough folk to outweigh the
> > largish change. And I definitely have VM _way_ higher up my personal
> > list. :)
> >
>
> I intend to chunk up the -aa VM patch and feed it into 2.4.19-pre.
> I think Andrea's OK with that. Just the VM and buffercache bits.
> Something also needs to be done about block-highmem and pte-highmem.
I've recommended block-highmem before, and I can do it again. If it
needs to be split a bit (I don't really think it does, though), I can
even do that too.
--
Jens Axboe
Hi Shawn,
On 25 Feb 2002, Shawn Starr wrote:
> Not to begin the flamewar, but no thanks. rmap-12f blows -aa away
> AFAIK on this P200 w/ 64MB ram.
Please don't repeat the errors of the past.
-- rmap should evolve some time more. We should keep it in a safe area
for a while to mature without being distracted by user confusion.
-- aa seams to be the needed fix for the current design
So please add the needed fixes for the current design and wait for the
next design to become ready.
Greetings
Christoph
On Mon, 25 Feb 2002, Martin J. Bligh wrote:
> >> rmap still sucks on large systems though.
> >
> > But this is not a fundamental issue, it's implementation.
> > Whereas non-rmap will always suck on large systems, for
> > fundamental reasons that are unrelated to the quality of
> > the implementation.
>
> Absolutely ... it's just not quite finished yet. I'm
> convinced it'll be a major win for everyone in the end,
> I just squirm a little when I see people advocating it
> going into the mainline right now.
To be honest, so do I.
We've seen Linus merge a large chunk of VM code into
2.4 twice now, both merges gave problems.
The way to start merging stuff is to add useful pieces
of code one by one, like Al Viro is slowly merging a
rewrite of the VFS without anyone noticing ;)
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
On Tue, Feb 26, 2002 at 08:07:12AM +0100, Christoph Hellwig wrote:
> Other -aa parts are much saner and if no one else does it will feed big
> parts to Marcelo.
>
You should talk to Andrew Morton, as he plans to do this also.
> > If we are somewhat risky we put Ingo's GREAT O(1)-scheduler in, too.
>
> Kill source compatiblity for drivers -> no way.
>
I thought the internals of the scheduler weren't exposed to the rest of the
kernel...
On Tue, Feb 26, 2002 at 08:21:12AM -0800, Mike Fedyk wrote:
> You should talk to Andrew Morton, as he plans to do this also.
Last time I talked to him he was primarily interested in the VM.
> I thought the internals of the scheduler weren't exposed to the rest of the
> kernel...
They shouldn't, But many old drivers do (and _had to_):
current->policy = SCHED_YIELD;
schedule();
which isn't possible with the new scheduler.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Thu, 28 Feb 2002, Bill Davidsen wrote:
> On Tue, 26 Feb 2002, Christoph Hellwig wrote:
>
> > They shouldn't, But many old drivers do (and _had to_):
> >
> > current->policy = SCHED_YIELD;
> > schedule();
> >
> > which isn't possible with the new scheduler.
>
> Let's see, the choices are to (a) keep the old scheduler which has many
> performance issues, or (b) put in the new scheduler and let people who
> need the old drivers either fix them or stop upgrading.
or (c) have proponents of the inclusion of the O(1) scheduler
fix all drivers before having the O(1) scheduler considered
for inclusion.
Adding a yield() function to 2.4's scheduler and fixing all
the drivers to use it isn't that hard. Now all that's needed
are some O(1) fans willing to do the grunt work.
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
On Tue, 26 Feb 2002, Christoph Hellwig wrote:
> They shouldn't, But many old drivers do (and _had to_):
>
> current->policy = SCHED_YIELD;
> schedule();
>
> which isn't possible with the new scheduler.
Let's see, the choices are to (a) keep the old scheduler which has many
performance issues, or (b) put in the new scheduler and let people who
need the old drivers either fix them or stop upgrading.
Bad performance should go the way of a.out kernels and xiafs (which at
least did have utility), not be justified as a way to force people to
patch their kernel.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> or (c) have proponents of the inclusion of the O(1) scheduler
> fix all drivers before having the O(1) scheduler considered
> for inclusion.
According to find and grep the patch in general use does precisely that
except for Andrea's yield loops on init kill funnies that still lurk in
the non x86 parts of rmap. If rmap doesnt need them I guess they should go ?
On Fri, 1 Mar 2002, Alan Cox wrote:
> > or (c) have proponents of the inclusion of the O(1) scheduler
> > fix all drivers before having the O(1) scheduler considered
> > for inclusion.
>
> According to find and grep the patch in general use does precisely that
> except for Andrea's yield loops on init kill funnies that still lurk in
> the non x86 parts of rmap. If rmap doesnt need them I guess they should go ?
Absolutely.
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
On Fri, 1 Mar 2002, Rik van Riel wrote:
> Not at all. The yield() function would just be a define to
> the code which no longer works with the new scheduler, ie:
>
> #define yield() \
> current->policy |= SCHED_YIELD; \
> schedule();
or better :
#define yield() \
do { \
current->policy |= SCHED_YIELD; \
schedule(); \
} while (0)
- Davide
On Thu, 28 Feb 2002, Bill Davidsen wrote:
> On Thu, 28 Feb 2002, Rik van Riel wrote:
> > or (c) have proponents of the inclusion of the O(1) scheduler
> > fix all drivers before having the O(1) scheduler considered
> > for inclusion.
> >
> > Adding a yield() function to 2.4's scheduler and fixing all
> > the drivers to use it isn't that hard. Now all that's needed
> > are some O(1) fans willing to do the grunt work.
>
> That sounds very nice, but in practice it means it would never happen,
> and you know it.
If you send the patch, it'll happen. If you don't have the
motivation to send the patch and nobody else has either, then
it won't happen.
> First you have to patch the existing scheduler.
Not at all. The yield() function would just be a define to
the code which no longer works with the new scheduler, ie:
#define yield() \
current->policy |= SCHED_YIELD; \
schedule();
> Aside from the work on something which we are about to discard, the
> patch would have to go through the maintainer, and the the submitter,
> If we could get a dispensation from Linus to submit one patch combining
> the scheduler and all the drivers, it could be done (almost mechanically).
You can send marcelo such a patch (without the scheduler) right
now.
You're making absolutely no sense when you're saying that a patch
without the O(1) scheduler would have to go through the maintainers
while a patch with the O(1) scheduler included could go into the
kernel directly.
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
On Thu, 28 Feb 2002, Rik van Riel wrote:
> On Thu, 28 Feb 2002, Bill Davidsen wrote:
> > On Tue, 26 Feb 2002, Christoph Hellwig wrote:
> >
> > > They shouldn't, But many old drivers do (and _had to_):
> > >
> > > current->policy = SCHED_YIELD;
> > > schedule();
> > >
> > > which isn't possible with the new scheduler.
> >
> > Let's see, the choices are to (a) keep the old scheduler which has many
> > performance issues, or (b) put in the new scheduler and let people who
> > need the old drivers either fix them or stop upgrading.
>
> or (c) have proponents of the inclusion of the O(1) scheduler
> fix all drivers before having the O(1) scheduler considered
> for inclusion.
>
> Adding a yield() function to 2.4's scheduler and fixing all
> the drivers to use it isn't that hard. Now all that's needed
> are some O(1) fans willing to do the grunt work.
That sounds very nice, but in practice it means it would never happen, and
you know it. First you have to patch the existing scheduler. Aside from
the work on something which we are about to discard, the patch would have
to go through the maintainer, and the the submitter, and the pope, and
god, and finally Linus, and then (only then) could the patch go in the old
scheduler. Then you start the process with each of the drivers. They are
old grotty drivers, I would bet that no one "maintains" some of them (I'll
actually count when I login to a better machine).
This process could take six months to a year, after which we can start the
process with the scheduler. Alternatively we can put in the new scheduler,
let the drivers have compile errors, and let them be fixed when (if) they
are still in use.
If we could get a dispensation from Linus to submit one patch combining
the scheduler and all the drivers, it could be done (almost mechanically).
But with the maintainers, submitters, etc, process for each bit, it could
take a year. And dammit the patch is so night and day better that it
shouldn't take a year.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
<massive snippage>
> 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.
> 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...
--
Dart
"I have studied many philosophers and many cats.
The wisdom of cats is infinitely superior." -- Hippolyte Taine
On Fri, Mar 01, 2002 at 12:13:08AM -0300, Rik van Riel wrote:
> You can send marcelo such a patch (without the scheduler) right
> now.
And it's even probably a better idea to send it without the scheduler.
It's a typical Al Viro[tm] patch, change a repeated group of code into
one macro/function with zero impact on the resulting code, only better
encapsulation. It is completely orthogonal to the scheduler, and
obviously low risk.
OG.
Excuse my stupidity, but would a patch that just adds Davide's macro and
changes all instances of
current->policy |= SCHED_YIELD;
schedule();
to yield() be acceptable? Is there more involved than that, because I am
perfectly happy to create and submit such a patch.
...or am I just being dumb?
Sean
On Thu, Feb 28, 2002 at 07:43:57PM -0800, Davide Libenzi wrote:
> On Fri, 1 Mar 2002, Rik van Riel wrote:
>
> > Not at all. The yield() function would just be a define to
> > the code which no longer works with the new scheduler, ie:
> >
> > #define yield() \
> > current->policy |= SCHED_YIELD; \
> > schedule();
>
> or better :
>
> #define yield() \
> do { \
> current->policy |= SCHED_YIELD; \
> schedule(); \
> } while (0)
>
>
>
> - Davide
>
>
> -
> 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/
>
On Thu, Feb 28, 2002 at 08:04:38PM -0300, Rik van Riel wrote:
> the drivers to use it isn't that hard. Now all that's needed
> are some O(1) fans willing to do the grunt work.
After a simple set of egreps, I've cobbled together a patch that adds
Davide's #define to include/linux/sched.h and modifies corresponding
places over the entire tree. It's coming separately.
--
Dan Chen [email protected]
GPG key: http://www.unc.edu/~crimsun/pubkey.gpg.asc
On Fri, 1 Mar 2002, Sean Hunter wrote:
> Excuse my stupidity, but would a patch that just adds Davide's macro and
> changes all instances of
>
> current->policy |= SCHED_YIELD;
> schedule();
>
> to yield() be acceptable? Is there more involved than that, because I am
> perfectly happy to create and submit such a patch.
>
> ...or am I just being dumb?
The purpose of the macro would be to create a compatibility layer to
1) cleanup 2.4.x code 2) facilitate o(1) sched integration
- Davide
On Fri, 1 Mar 2002, dart wrote:
> <massive snippage>
>
> > 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.
> > 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.
> 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 ;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> 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
> 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
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
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.
--
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/
On Wednesday 06 March 2002 02:45, 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.
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 :-)
--
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.
--
Best regards,
Leonid Mamtchenkov, RHCE
System Administrator
Francoudi & Stephanou Ltd.