Tim Waugh (tim@cyberelk.demon.co.uk)
Tue, 15 Dec 1998 22:09:46 +0000 (GMT)
On Tue, 15 Dec 1998, Andrea Arcangeli wrote:
> >For me, the load is 0.00 while printing.
>
> Hmm how long is your printing in time? ;). /proc/loadavg needs 5 minutes
> of printing to show up a reliable value.
It was 0.00 for a good few pages. I didn't time it.
> 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?
> >This looks dubious. All it means, if the semaphore is signalled, is that
> >fast polling may have worked before resorting to interrupts. If that were
> >_never_ true for anyone, perhaps I'd agree with your patch that takes out
> >fast polling.
>
> I can' t understand very well here, but I agree that my brute patch could
> have killed polling (that I never use btw).
Let's not forget that polling is (and will continue to be) the default.
> 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_.
This is true even when we are using interrupts.
> Hmm, yes, probably I have not interpreded well the point of the timeout
> handling code there. If I understand well such code should be emergency
> code. Right? My point was that we must release the port only according to
> parport_yield_blocking to be efficient and assure a good timeslice for
> every pardevice...
The code in question was something like this:
do {
give printer 40ms to comply
if we poll, release the port
wait a long time
if we poll, claim the port back
} while printer busy
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".
> >> /* Wait longer next time. */
> >> - if (wait < (port->ieee1284.timeout / 2))
> >> - wait *= 2;
> >> + if (wait < (port->ieee1284.timeout >> 1))
> >> + wait <<= 1;
> >
> >Can't the compiler figure that out? Anyway, I think the 2s make the code
> >easier to read.
>
> Yes, the patch is pure estethic.
Esthetic? Not to my eye.
Tim.
*/
-- 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