Killing the Big Kernel Lock
in [Kernel]
|
Prev: Darlehen bieten bei 2% Zins (Union beschränkt Finanzierung)
Next: [PATCH] rt2500usb: improve powersaving reliability
From: Roland Dreier on 24 Mar 2010 18:00 Hi Arnd, Interesting work. For the drivers/infiniband part, it seems maybe all these drivers should be using no_llseek instead of default_llseek? (or is it better style to use nonseekable_open()?) Certainly as far as I can tell, nothing in drivers/infiniband pays any attention to f_pos. Also, is there a reason why you add "#include <linux/smp_lock.h>" to all the files where you also do ".llseek = default_llseek"? In any case I can at least take care of the llseek stuff for 2.6.35. - R. -- Roland Dreier <rolandd(a)cisco.com> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- 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: Arnd Bergmann on 24 Mar 2010 18:10 On Wednesday 24 March 2010 22:53:07 Roland Dreier wrote: > Interesting work. For the drivers/infiniband part, it seems maybe all > these drivers should be using no_llseek instead of default_llseek? (or > is it better style to use nonseekable_open()?) Certainly as far as I > can tell, nothing in drivers/infiniband pays any attention to f_pos. no_llseek makes it clear that you don't want the default_llseek semantics, while nonseekable_open also prevents pread/pwrite. Ideally, I'd just use both. There is a small chance that a random user space application actually tries to seek on the device (e.g. SEEK_END) and expects a zero return value, so when in doubt, I converted everything to default_llseek instead of no_llseek, just so I can be sure I don't change the semantics. > Also, is there a reason why you add "#include <linux/smp_lock.h>" to all > the files where you also do ".llseek = default_llseek"? The last patch in the series moves the default_llseek and default_ioctl function into the same loadable module that contains the BKL itself. Moving the declarations into the respective header seemed appropriate, but it could also stay in a VFS header if people prefer that. > In any case I can at least take care of the llseek stuff for 2.6.35. Ok, thanks! Arnd -- 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 24 Mar 2010 18:10 > - The most invasive change is in the TTY layer, which has a new global > mutex (sorry!). I know that Alan has plans of his own to remove the BKL > from this subsystem, so my patches may not go anywhere, but they seem > to work fine for me. > I've called the new lock the 'Big TTY Mutex' (BTM), a name that probably > makes more sense if you happen to speak German. Chuckle (I don't but I looked it up) > The basic idea here is to make recursive locking and the release-on-sleep > explicit, so every mutex_lock, wait_event, workqueue_flush and schedule > in the TTY layer now explicitly releases the BTM before blocking. I'm not sure if that is actually the path of sanity (yours at least), nor the right way to whack the other BKL users whose use is horrible but essentially private. It would be nice to get the other bits in first removing BKL from most of the kernel and building kernels which are non BKL except for the tty layer. That (after Ingo's box from hell has run it a bit) would reasonably test the assertion that the tty layer has no BKL requirements that are driven by external to tty layer code. That to me would test the biggest question of all and be a reasonably good base from which to then either apply the tty BTM patches or attack the problem properly with the BKL localised to one subtree. 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 24 Mar 2010 18:30 * Arnd Bergmann <arnd(a)arndb.de> wrote: > I've built-tested an allmodconfig kernel with CONFIG_BKL disabled on x86_64, > i386, powerpc64, powerpc32, s390 and arm to make sure I catch all the > modules that depend on BKL, and I've been running various versions of this > tree on my desktop machine over the last few weeks while adding stuff. Very nice work! How about going one step further: - remove CONFIG_BKL altogether - remove all the remains of the BKL code in lib/kernel_lock.c and kernel/sched.c - turn lock_kernel() into a WARN_ONCE() and unlock_kernel() into a NOP. - ... - Celebrate! :-) 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: Arnd Bergmann on 24 Mar 2010 18:30
On Wednesday 24 March 2010 23:10:16 Alan Cox wrote: > > The basic idea here is to make recursive locking and the release-on-sleep > > explicit, so every mutex_lock, wait_event, workqueue_flush and schedule > > in the TTY layer now explicitly releases the BTM before blocking. > > I'm not sure if that is actually the path of sanity (yours at least), nor > the right way to whack the other BKL users whose use is horrible but > essentially private. > > It would be nice to get the other bits in first removing BKL from most of > the kernel and building kernels which are non BKL except for the tty > layer. That (after Ingo's box from hell has run it a bit) would > reasonably test the assertion that the tty layer has no BKL requirements > that are driven by external to tty layer code. Yes, we can do that by applying all patches except 'tty: implement BTM as mutex instead of BKL', which is the only one in the tty section of my series that should really change the behaviour. Building a kernel with all other BKL users gone currently implies disabling usbcore, videodev, soundcore, i4l and capi, as well as a large number of obsolete device drivers. The only ones that I can imagine still interacting with the tty code are the ISDN drivers, and even those look pretty unlikely. > That to me would test the biggest question of all and be a reasonably > good base from which to then either apply the tty BTM patches or attack > the problem properly with the BKL localised to one subtree. We could also make the 'tty: implement BTM as mutex instead of BKL' patch a config option that makes it possible to test it out some more while conservative users just continue to get the BKL semantics. Arnd -- 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/ |