Hi,
I'm very much a newbie, and I'm wondering about the big kernel locks
in tty_io.c. What exactly are the locks in the read and write for? Is the
tty device that contested? Couldn't a finer grained lock be used?
-Alex Khripin
On Wed, 2002-01-30 at 13:49, Alex Khripin wrote:
> I'm very much a newbie, and I'm wondering about the big kernel locks
> in tty_io.c. What exactly are the locks in the read and write for? Is the
> tty device that contested? Couldn't a finer grained lock be used?
It has less to do with lock contention and much more to do with the
design of the tty / console layer. It isn't the kernel's prettiest
code.
There is probably some cleanup that is possible, but really getting the
thing in gear (which means no BKL, which is probably the hardest part to
rip out) require some level of rewrite.
Robert Love
On Wed, Jan 30, 2002 at 02:25:59PM -0500, Robert Love wrote:
> It has less to do with lock contention and much more to do with the
> design of the tty / console layer. It isn't the kernel's prettiest
> code.
>
> There is probably some cleanup that is possible, but really getting the
> thing in gear (which means no BKL, which is probably the hardest part to
> rip out) require some level of rewrite.
I've been thinking about the serial layer, and its far from trivial.
Unless its done right, we'll end up with a mess of locks -> deadlock.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Robert Love wrote:
>On Wed, 2002-01-30 at 13:49, Alex Khripin wrote:
>
>>I'm very much a newbie, and I'm wondering about the big kernel locks
>>in tty_io.c. What exactly are the locks in the read and write for? Is the
>>tty device that contested? Couldn't a finer grained lock be used?
>>
>There is probably some cleanup that is possible, but really getting the
>thing in gear (which means no BKL, which is probably the hardest part to
>rip out) require some level of rewrite.
>
People working on BKL removal tend to ignore these types of things (I
know I do). We concentrate on scalability and performance and the tty
code isn't exactly a high point of lock contention.
>There is probably some cleanup that is possible, but really getting the
>thing in gear (which means no BKL, which is probably the hardest part to
>rip out) require some level of rewrite.
Is there a specific maintainer for the TTY code. This is the part of the
kernel which I am most interested in. I have many TTYs in a mid size (100
user Unix network) and could get to do some testing if anyone is writing
patches for this system. I would also be willing to do minor review of code
for spelling and such. I would _really_ like to get involved with this
specific system.
Thanks,
Karl Tatgenhorst
> > I'm very much a newbie, and I'm wondering about the big kernel locks
> > in tty_io.c. What exactly are the locks in the read and write for? Is the
> > tty device that contested? Couldn't a finer grained lock be used?
>
> It has less to do with lock contention and much more to do with the
> design of the tty / console layer. It isn't the kernel's prettiest
> code.
>
> There is probably some cleanup that is possible, but really getting the
> thing in gear (which means no BKL, which is probably the hardest part to
> rip out) require some level of rewrite.
I'm working on it in the DJ tree. I'm going from the lowest level up to
the tty layer. I agree with about the BKL. I plan to move
acquire_console_lock into the tty lock shortly. No reason that only the VT
system should be able to take advantage of it. I also plan to implement
that lock on a per hardware device level instead of a general global lock.
This will solve alot of problems. Plus their is no reason why serial
devices or VT tty system have to reimplement the wheel.
> > There is probably some cleanup that is possible, but really getting the
> > thing in gear (which means no BKL, which is probably the hardest part to
> > rip out) require some level of rewrite.
>
> I've been thinking about the serial layer, and its far from trivial.
> Unless its done right, we'll end up with a mess of locks -> deadlock.
All the locking should be moved to the upper tty layers. Why implement the
wheel over and over agin for each type of tty device.
> Is there a specific maintainer for the TTY code. This is the part of the
> kernel which I am most interested in. I have many TTYs in a mid size (100
> user Unix network) and could get to do some testing if anyone is writing
> patches for this system. I would also be willing to do minor review of code
> for spelling and such. I would _really_ like to get involved with this
> specific system.
Thedore Tyso was originally the maintainer but he seems to have
disappeared from the face of the earth. For the past year I have been
working on a totally rewrite of the tty/console system.
On Wed, Jan 30, 2002 at 02:58:29PM -0800, James Simmons wrote:
> All the locking should be moved to the upper tty layers. Why implement the
> wheel over and over agin for each type of tty device.
By that statement, I can see that you haven't really done any analysis of
the tty nor serial locking. Its not a simple case of "just add a per tty
semaphore in the tty layer and everything will be fine".
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Mr. King,
I tried to send this to your e mail address but I think your spam filter
doesn't like me. I am very interested in getting involved with any
(low)level work with the TTY system in Linux I work as a Unix admin with a
network of serial devices and PCS. I have found that I want specifically to
learn to understand serial TTY communication. (Unfortunately my coding
skills are about enough to read code and understand it, I have no design
skills yet) as I said though I would love to test stuff for you or anyone
active in this. That would allow me to learn it and apply my own knowledge
of TTY implementations from AIX and Unixware.
For testing I have an Ibm Netfinity with an Equinox Multi Port Card (I am
interested in multi port devices) running RH 7.2 with the 4.17 Stable
Kernel. I also have an IBM RS6000 which I hope to get running Linux soon (it
too has a multi port card). Both cards are 128 port serial.
I look forward to hearing more you.
Karl Tatgenhorst
> On Wed, Jan 30, 2002 at 02:58:29PM -0800, James Simmons wrote:
> > All the locking should be moved to the upper tty layers. Why implement the
> > wheel over and over agin for each type of tty device.
>
> By that statement, I can see that you haven't really done any analysis of
> the tty nor serial locking. Its not a simple case of "just add a per tty
> semaphore in the tty layer and everything will be fine".
I have to say no. I have been to busy cleaning up the fbdev layer right
now. What I have done is work on a way to haev each console device have
its own lock and then share that with struct tty_driver to protect
hardware access. This is just the first step. I knew the tty layer would
require more than just that. Since I haven't had time to look at all the
details I'm curious to what you have discovered. I still believe that
locking could be moved to the upper layer tho. I don't see why not.