User: Password:
|
|
Subscribe / Log in / New account

BKL-free in 2.6.37 (maybe)

BKL-free in 2.6.37 (maybe)

Posted Sep 23, 2010 9:16 UTC (Thu) by marcH (subscriber, #57642)
Parent article: BKL-free in 2.6.37 (maybe)

> If all goes well, 2.6.37 will have a configuration option which makes BKL-free builds possible. That's a huge step forward, even if the BKL still exists in most stock kernels.

Suppose the BKL has just become optional. As a *user*, suppose I do not use *any* module or code using the BKL. Would it make any difference to me to run a BKL-free kernel compared to a stock kernel compiled with most features, including an unused BKL?

> The Amiga FFS, for example, cannot have received much maintenance in recent times, and seems unlikely to have a lot of users.
> [...] [...] [...]
> In some cases, the remaining BKL-using code might be shifted over to the staging tree and eventually removed entirely if it is not fixed up.

In such cases isn't it better to just let this suboptimal but tested and working code depend forever on an optional BKL? The few remaining users of such old code might still enjoy it without having the resources to free it from the BKL.


(Log in to post comments)

BKL-free in 2.6.37 (maybe)

Posted Sep 23, 2010 12:14 UTC (Thu) by NAR (subscriber, #1313) [Link]

In such cases isn't it better to just let this suboptimal but tested and working code depend forever on an optional BKL?

Do you mean tested 10 years ago and was possibly working 10 years ago? I remember an article here about a kernel module that wasn't even compiling for some 4 years and nobody noticed.

Kernel developers sometimes boast about having features with a user community numbering in single digits. Do you think these extremely rarely used features are actually working with every kernel release?

BKL-free in 2.6.37 (maybe)

Posted Sep 23, 2010 14:20 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Do you mean tested 10 years ago and was possibly working 10 years ago?

No: I meant in small but non-zero use still today. Replace "Amiga FFS" by a more appropriate example if required.

> I remember an article here about a kernel module that wasn't even compiling for some 4 years and nobody noticed.

I wasn't considering such extreme cases. This seems rather off-topic since nobody cares whether such broken modules use the BKL or not.

BKL-free in 2.6.37 (maybe)

Posted Sep 23, 2010 14:48 UTC (Thu) by cesarb (subscriber, #6266) [Link]

> In such cases isn't it better to just let this suboptimal but tested and working code depend forever on an optional BKL?

If every use of the BKL is removed, the code which magically releases and reacquires it on a context switch can also be removed. This cannot be done if there is even one single user.

Not to mention that it is also a good canary for bit-rotted code. It is most probably not "tested and working code"; said code usually depended on some property of the environment which has now changed (this is how bit rot happens).

BKL-free in 2.6.37 (maybe)

Posted Sep 23, 2010 19:00 UTC (Thu) by arnd (subscriber, #8866) [Link]

> Suppose the BKL has just become optional. As a *user*, suppose I do not use *any* module or code using the BKL.
> Would it make any difference to me to run a BKL-free kernel compared to a stock kernel compiled with most features,
> including an unused BKL?

Not much. The task_struct can shrink by four bytes and the schedule() function loses a few bytes for calling release_kernel_lock()/reaquire_kernel_lock().

The -rt kernel tree wins a bit more because it does not have to work around the BKL being weird any more.

If we get distros to disable the BKL while it's still there, that will help annoy certain companies providing binary-only kernel modules, but if you're building your own kernels and don't use those modules, it won't make a difference.

I originally thought we'd have a lot more legacy modules that are not worth fixing and need to be disabled, but now the config option is not so important any more.

> In such cases isn't it better to just let this suboptimal but tested and working code depend forever on an optional BKL?
> The few remaining users of such old code might still enjoy it without having the resources to free it from the BKL.

The only remaining modules that nobody has volunteered to fix are now only i810/i830 (drm), and a few file systems (adfs, coda, freevxfs, hpfs, smbfs and ufs). I guess we can either declare them BROKEN_ON_SMP or remove them if nobody steps up to fix them by the end of the following (2.6.38) merge window.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds