Messages in this thread | | | Date | Mon, 10 Jul 2006 23:33:18 -0400 | From | "Jon Smirl" <> | Subject | Re: tty's use of file_list_lock and file_move |
| |
On 7/10/06, Theodore Tso <tytso@mit.edu> wrote: > On Mon, Jul 10, 2006 at 07:49:31PM -0400, Jon Smirl wrote: > > How about the use of lock/unlock_kernel(). Is there some hidden global > > synchronization going on? Every time lock/unlock_kernel() is used > > there is a tty_struct available. My first thought would be to turn > > this into a per tty spinlock. Looking at where it is used it looks > > like it was added to protect all of the VFS calls. I see no obvious > > coordination with other ttys that isn't handled by other locks. > > No, it was just a case of not being worth it to get rid of the BKL for > the tty subsystem, since opening and closing tty's isn't exactly a > common event. Switching it to use a per-tty spinlock makes sense if > we're going to rototill the code, but to be honest it's probably not > going to make a noticeable difference on any benchmark and most > workloads.
I tried changing it to a per tty spinlock. Now I know that the code relies on the BKL being broken when a task sleeps. That's a part of the BKL I don't like, unlocks are happening implicitly instead of explicitly. I always wonder if the code should have reacquired the BKL when it woke up. In this case the sleep happens inside the line discipline read functions.
Now I'm wondering if read and write should have taken BKL to begin with. Read sleeps in a loop so after the first pass it has lost the BKL. Read and write also have the own locking code internally.
-- Jon Smirl jonsmirl@gmail.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |