Philip Blundell (pb@nexus.co.uk)
Wed, 16 Dec 1998 10:57:37 +0100
>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...
No; if your printer is very fast then the right thing to do is just to reduce
the udelay() inside the polling loop.
Imagine your printer takes 5us to process a byte for example. If you never
poll and instead just rely on the IRQ then you will end up going to sleep
immediately, getting an irq after 5 microseconds and then waking up again.
This means that the scheduler gets invoked twice per byte printed but the
overhead of this and the IRQ handling will completely wipe out the opportunity
for any useful work to get done in that time. You might as well not bother.
If the printer is faster things get worse, not better -- completely IRQ-driven
printing is only a reasonable thing to do if you expect long delays a
substantial fraction of the time.
For most people, printing at a reasonable speed is more important than
reducing CPU loading while the port is in use.
p.
-- 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