[PARPORT] Re: patch-2.1.131-ac8-1284

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.


-- 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