David Campbell (campbell@gear.torque.net)
Mon, 9 Feb 1998 09:15:09 +0000
> To: Trond Eivind Glomsrod <teg@pvv.ntnu.no>
> Subject: Re: [PARPORT] Re: lpr problems in 2.0->2.1?
> Cc: linux-kernel@vger.rutgers.edu, linux-parport@torque.net
> Date: Mon, 9 Feb 1998 06:45:43
> > >For me, that has made the printer _really_ slow - the data is
> > >transferred in chunks, so the printer pauses for quite some time a
> > >few times for every page, while the same setup prints continually (and
> >
> > If you're getting worse performance under 2.1 then you should report it as a
> > bug. It's not supposed to be like that. If you are actually using a Zip
> > driver at the same time then printing speed will go down, but otherwise it
> > should be just as good.
>
> The problem is most likely that the current lp driver is evaluating the
> parallel port base address every IO access. A similar problem reduced the
> speed of the ZIP drive by approx 50% until a port caching scheme was
> implemented.
I was wrong, the problem is a little more complicated than first thought.
Due to the parport design (to allow for devices such as the ZIP drive to
operate on different types of hardware) there exists functions for writing
to "virtual" PC hardware.
For PC style hardware this is simply port accesses, for other hardware the
bits are remapped before being sent to the device.
[At this point I start looking for HARD cover]
This is a question for the kernel hackers:
a) Is there any way to reduce the overhead of a function call?
b) Is it possible to construct functions on the fly?
That is copy a compiled fuction to some scratch space, change the constant
(port address) and then hook the fuction onto the supporting structure.
This way it would save looking for the port address for every IO access.
This would save about 3 CPU instructions per port access, this may not
look much but it adds up when you are performing approx 300,000 per
second. (this rate would be reached when sending 100kB/sec to the printer
port, the ZIP drive can reach approx 500,000 port accesses/sec).
Admittedly it would require a scratch space area in the CODE segment which
could be written too (EXTREMELY dangerous).
The result would then be:
==========================================
x = parport->read_control();
parport->write_control(x & 0x20);
==========================================
Currently the function needs to be passed the underlying structure to be
able to determine the base port address.
c) Create a virtual device which maps PC hardware requests for non-PC
systems (at some unused address). So when the kernel accesses the phantom
port an exception is generated and handled by the translation routines.
Nahh!!! To much like Win95.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
At this point I turn up my heat sheild to anti-nuclear levels...
If someone has a better suggestion I would like to hear it!!!
David Campbell
PS: I am not a member of the linux-kernel mailing list, so please email me
directly your response.
=======================================================
campbell@torque.net (Parallel port device related mail)
dcampbel@p01.as17.honeywell.com.au (For all other mail)
"All parallel ports are equal - Some are more equal than others"
-- 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:17:27 EST