Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [GIT, RFC] Killing the Big Kernel Lock | Date | Wed, 24 Mar 2010 23:25:23 +0100 |
| |
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
| |