Andrea Arcangeli (andrea@e-mind.com)
Tue, 15 Dec 1998 23:56:46 +0100 (CET)
On Tue, 15 Dec 1998, Tim Waugh wrote:
>> Tim, now I don' t trust your 0.00 load because your stock patch was
>
>Disregard it then. Are you saying that a process using up 200usecs of its
>10ms timeslice was causing a noticeable slow-down?
My printer was too fast and the _kernel_ code was not rescheduing
properly, this is the reason of the machine overload. So it was not
rescheduling at all. And btw the timeslice of a process should be the
DEFAULT_PRIORITY * HZ.
>> But I am pretty sure that irq printing need the code commented out to
>> be rasonable efficient at least on Stylus Color (and I guess on many
>> other new printers). Can somebody out there confirm this on some other
>> hardware?
>
>_WHY_? Andrea, I have a niced rc5des process continuously runnable. I
>expect to get reasonable throughput to the printer, and 100 characters a
>second doesn't count. If the printer isn't ready _immediately_ and we
>schedule because of it, that's _bad_.
Hmm, I see your point but your hardware is not the only one out there
(this is why I asked to people). I (Stylus Color 740) for example need to
go down() ASAP. My printer is very very fast and to have 1 chance to be
CPU light I myst sleep on the irq ASAP without poll in a kernel loop.
With the old lp I was used to play with tunelp -c 1. With the IEEE1284
code right now we are going to penalyzing somebody as expected (-w 1 issue
too) since sound less tunable (at least as it' s now).
I know your hardware is not efficient sleeping on the irq as first thing.
To be efficinet you need to poll for awhile. You mainly use irq only for
long delays while I can use it always without lose performance and being
very lighter...
>This is true even when we are using interrupts.
The point is that in polling, when you schedule() you are sure that you'
ll be out for a lot of time even if the hardware will be ready a bit after
the schedule(). With irqs instead you have more chance to run before due
up() reschedule_idle() and friends...
>Now what's wrong with that? If we poll, what's the point in keeping the
>port held while we wait for something like 5 seconds? If you're worried
>that playing with linked lists takes a long time, worry more about the
>line that says "wait a long time".
OK.
Andrea Arcangeli
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:55 EST