TTY patches for 2.6.33-git
in [Kernel]
|
Prev: Badness at net/ipv4/inet_connection_sock.c:293
Next: RCU detected CPU 0 stall after panic on sparc64
From: Alan Cox on 12 Dec 2009 21:00 > I think we could possibly add a "__might_sleep()" to _lock_kernel(). It > doesn't really sleep, but it's invalid to take the kernel lock in an > atomic region, so __might_sleep() might be the right thing anyway. It's only invalid if you don't already hold the lock. The old tty code worked because every path into tty_fasync already held the lock ! That specific case - taking it the first time should definitely __might_sleep(). Mind you it's probably still rather dumb and would be a good debugging aid for -next to be able to warn on all offences if only to catch this stuff for the future BKL removal work. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 13 Dec 2009 02:00 * Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > We've had quite a bit of BKL work this merge-window. Maybe we'll even get > rid of it one of these days. There are "only" about 600 instances of > "lock_kernel()" in the tree right now ;) I tend to use unlock_kernel() as the metric. (as it's more precisely greppable and it is also more indicative of the underlying complexity of locking, as it gets used more in more complex scenarios) In the last ~4.5 years: earth4:~/tip> git checkout v2.6.12 Date: Fri Jun 17 12:48:29 2005 -0700 earth4:~/tip> git grep -w unlock_kernel | wc -l 713 earth4:~/tip> git checkout linus Date: Fri Dec 11 20:58:20 2009 -0800 earth4:~/tip> git grep -w unlock_kernel | wc -l 841 we grew the (absolute) number of BKL sites by ~15%. Certainly the kernel grew at a much faster rate, so the relative proportion of the BKL shrunk. Also, a lot of BKL use was hidden before, and due to the BKL removal activities (by Thomas, Frederic, Jon, Alan and others) the remaining BKL using sites are a lot more well defined, a lot more isolated and thus a lot more removable than ever before. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 13 Dec 2009 06:40 > earth4:~/tip> git checkout linus > Date: Fri Dec 11 20:58:20 2009 -0800 > earth4:~/tip> git grep -w unlock_kernel | wc -l > 841 > > we grew the (absolute) number of BKL sites by ~15%. Certainly the kernel grew > at a much faster rate, so the relative proportion of the BKL shrunk. Thats actually very misleading. The reason is we have created more lock/unlock points as we remove and drive down the lock. By your metric the original SMP kernel was best - it had one of each 8) > Also, a lot of BKL use was hidden before, and due to the BKL removal > activities (by Thomas, Frederic, Jon, Alan and others) the remaining BKL using > sites are a lot more well defined, a lot more isolated and thus a lot more > removable than ever before. ioctl is almost done and I've gont some other random ones in my tree. lseek is close. At that point most of the nasties are squashed except tty. We do have some remaining locking horrors some partly introduced by the finer locking work in the past including the rather nasty device unload/load v open file handle races. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 13 Dec 2009 07:20 * Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > > earth4:~/tip> git checkout linus > > Date: Fri Dec 11 20:58:20 2009 -0800 > > earth4:~/tip> git grep -w unlock_kernel | wc -l > > 841 > > > > we grew the (absolute) number of BKL sites by ~15%. Certainly the kernel grew > > at a much faster rate, so the relative proportion of the BKL shrunk. > > Thats actually very misleading. [...] Somewhat, so i qualified it with the next paragraph: > > Also, a lot of BKL use was hidden before, and due to the BKL removal > > activities (by Thomas, Frederic, Jon, Alan and others) the remaining BKL > > using sites are a lot more well defined, a lot more isolated and thus a > > lot more removable than ever before. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 13 Dec 2009 12:50
On Sun, 13 Dec 2009, Ingo Molnar wrote: > > In the last ~4.5 years: > > earth4:~/tip> git checkout v2.6.12 > Date: Fri Jun 17 12:48:29 2005 -0700 > earth4:~/tip> git grep -w unlock_kernel | wc -l > 713 > > earth4:~/tip> git checkout linus > Date: Fri Dec 11 20:58:20 2009 -0800 > earth4:~/tip> git grep -w unlock_kernel | wc -l > 841 Git hint of the day: you don't need to check out a kernel to do "git grep". Do this: git grep -w unlock_kernel v2.6.12 | wc and it will JustWork(tm). > Also, a lot of BKL use was hidden before, and due to the BKL removal > activities (by Thomas, Frederic, Jon, Alan and others) the remaining BKL using > sites are a lot more well defined, a lot more isolated and thus a lot more > removable than ever before. That's the main thing. We've been pushing them down a lot. We still have a few annoying core ones, though. I hate the execve() and file locking ones. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |