[arch-general] kernel 2.6.37 BKL
Devs, Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
On Thu, Jan 6, 2011 at 12:51 AM, Matthew Monaco <dgbaley27@verizon.net> wrote:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
Leave it enabled. It's important for compatibility with older drivers.
On Wednesday, January 05, 2011 05:51:02 pm Matthew Monaco wrote:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
What is BKL?
On 01/05/2011 07:23 PM, Jan Steffens wrote:
On Thu, Jan 6, 2011 at 12:51 AM, Matthew Monaco<dgbaley27@verizon.net> wrote:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
Leave it enabled. It's important for compatibility with older drivers.
The thing is, and this might be an indictment against me, I had heard it's required for v4l, but I compiled without BKL and my webcam works fine.
On Wed, 5 Jan 2011 18:28:42 -0600 Yaro Kasear <yaro@marupa.net> wrote:
On Wednesday, January 05, 2011 05:51:02 pm Matthew Monaco wrote:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
What is BKL?
The Big Kernel Lock, search the Web there are plenty of explanations. A short description is, that it is from the beginning of the Multiprocessor support by Linux which prevents conflicts created by doing some stuff at the central Kernel structures at the same time. -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
On Wed, 2011-01-05 at 19:45 -0500, Matthew Monaco wrote:
On 01/05/2011 07:23 PM, Jan Steffens wrote:
On Thu, Jan 6, 2011 at 12:51 AM, Matthew Monaco<dgbaley27@verizon.net> wrote:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
Leave it enabled. It's important for compatibility with older drivers.
The thing is, and this might be an indictment against me, I had heard it's required for v4l, but I compiled without BKL and my webcam works fine.
At this point in time leaving it enabled for compatibility in kernel26 is fine IMO. Those who need it disabled for specific reasons (the one I can think of is task latency for audio) should already be used to compiling patched kernels, so it wouldn't be a big deal for now.
2011/1/5 Ng Oon-Ee <ngoonee@gmail.com>:
At this point in time leaving it enabled for compatibility in kernel26 is fine IMO. Those who need it disabled for specific reasons (the one I can think of is task latency for audio) should already be used to compiling patched kernels, so it wouldn't be a big deal for now.
+1 for patched kernels for audio (including kernel26-rt) in community
At this point the BKL doesn't cause much performance loss: "The Big Kernel Lock is a giant lock that was introduced in Linux 2.0, when Alan Cox introduced SMP support for first time. But it was just an step to achieve SMP scalability - only one process can run kernel code at the same time in Linux 2.0, long term the BKL must be replaced by fine-grained locking to allow multiple processes running kernel code in parallel. In this version, it is possible to compile a kernel completely free of BKL support. Note that this doesn't have performance impact: all the critical Linux codepaths have been BKL-free for a long time. It still was used in many non-performance critical places -ioctls, drivers, non-mainstream filesystems, etc-, which are the ones that are being cleaned up in this version. But the BKL is being replaced in these places with mutexes, which doesn't improve parallelism (these places are not performance critical anyway). " From http://kernelnewbies.org/LinuxChanges#head-67c8ee4ffc27a012ae3d5349377b1dc44... On Wed, Jan 5, 2011 at 8:38 PM, Bernardo Barros <bernardobarros2@gmail.com> wrote:
2011/1/5 Ng Oon-Ee <ngoonee@gmail.com>:
At this point in time leaving it enabled for compatibility in kernel26 is fine IMO. Those who need it disabled for specific reasons (the one I can think of is task latency for audio) should already be used to compiling patched kernels, so it wouldn't be a big deal for now.
+1 for patched kernels for audio (including kernel26-rt) in community
-- Alexander Lam
On 6 January 2011 09:38, Bernardo Barros <bernardobarros2@gmail.com> wrote:
2011/1/5 Ng Oon-Ee <ngoonee@gmail.com>:
At this point in time leaving it enabled for compatibility in kernel26 is fine IMO. Those who need it disabled for specific reasons (the one I can think of is task latency for audio) should already be used to compiling patched kernels, so it wouldn't be a big deal for now.
+1 for patched kernels for audio (including kernel26-rt) in community
* That is still far behind in kernel revision * The removal of the BKL essentially means no need of a patched kernel for realtime preemption * A lot of the realtime preemption code has to be moved into mainline to utilise the benefit of a lock-free kernel "Why this matters from my perspective is that with the removal of BKL, Linux can now become even more real-time in the mainline. as well as potentially improve performance and control through the kernel." From: http://blog.internetnews.com/skerner/2010/11/linux-2637-kills-the-big-kerne.... The big word is "can".
Am 06.01.2011 00:51, schrieb Matthew Monaco:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
Let's disable it and see how long it takes for people to notice that they can't mount DVDs without UDF support.
On Wed, Jan 05, 2011 at 11:38:41PM -0200, Bernardo Barros wrote:
2011/1/5 Ng Oon-Ee <ngoonee@gmail.com>:
At this point in time leaving it enabled for compatibility in kernel26 is fine IMO. Those who need it disabled for specific reasons (the one I can think of is task latency for audio) should already be used to compiling patched kernels, so it wouldn't be a big deal for now.
+1 for patched kernels for audio (including kernel26-rt) in community
+1 -- FA There are three of them, and Alleline.
On Thu, 2011-01-06 at 10:50 +0100, Thomas Bächler wrote:
Am 06.01.2011 00:51, schrieb Matthew Monaco:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
Let's disable it and see how long it takes for people to notice that they can't mount DVDs without UDF support.
Sounds convincing to me =p
It seems like there is already agreement to keep BKL enabled, but for what it's worth here are my two cents: As explained by Andi Kleen <http://halobates.de/blog/p/56>, the disabling of BKL has no impact on end users. The benefit might come later, as the absence of BKL allows optimizations to be made. However, for the time being there is no benefit in removing it, and as Thomas pointed out, some functionality would be lost (Matthew: the v4l subsystem was fixed to work without BKL, that's why it still works for you :) ). Cheers, Tom
On 06.01.2011 10:50, Thomas Bächler wrote:
Am 06.01.2011 00:51, schrieb Matthew Monaco:
Devs,
Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.
Let's disable it and see how long it takes for people to notice that they can't mount DVDs without UDF support.
we are bleeding edge and optical disks are so 90's! :)
Am 07.01.2011 01:16, schrieb Ulf Winkelvos:
we are bleeding edge and optical disks are so 90's!
You shouldn't let this any gamer hear, although most of them are properly using windows for that ;). Best regards, Karol Babioch
At Samstag, 8. Januar 2011 01:17 Karol Babioch wrote:
You shouldn't let this any gamer hear, although most of them are properly using windows for that ;).
I don't think that using UDF with DVD-RAM is only important for gamer.-) See you, Attila
participants (14)
-
Alexander Lam
-
Attila
-
Bernardo Barros
-
fons＠kokkinizita.net
-
Jan Steffens
-
Karol Babioch
-
Matthew Monaco
-
Ng Oon-Ee
-
Ray Rashif
-
Thomas Bächler
-
Thorsten Töpper
-
Tom Gundersen
-
Ulf Winkelvos
-
Yaro Kasear