[arch-general] kernel 2.6.37 BKL - Arch-general - lists.archlinux.org

newer
[arch-general] Kernel error

[arch-general] kernel 2.6.37 BKL

older
[arch-general] gnucash in [extra]

Matthew Monaco

5 Jan 2011 5 Jan '11

11:51 p.m.

Devs, Any plans about the BKL setting in .37? I've been running the rc's without it for a while now.

Show replies by date

Jan Steffens

6 Jan 6 Jan

12:23 a.m.

On Thu, Jan 6, 2011 at 12:51 AM, 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.

Leave it enabled. It's important for compatibility with older drivers.

Matthew Monaco

12:45 a.m.

On 01/05/2011 07:23 PM, Jan Steffens wrote:

On Thu, Jan 6, 2011 at 12:51 AM, 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.

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.

Ng Oon-Ee

1:20 a.m.

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 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.

Bernardo Barros

1:38 a.m.

2011/1/5 Ng Oon-Ee :

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

1:57 a.m.

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 wrote:

2011/1/5 Ng Oon-Ee :

...
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

Ray Rashif

7:04 a.m.

On 6 January 2011 09:38, Bernardo Barros wrote:

2011/1/5 Ng Oon-Ee :

...
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".

fons＠kokkinizita.net

9:54 a.m.

On Wed, Jan 05, 2011 at 11:38:41PM -0200, Bernardo Barros wrote:

2011/1/5 Ng Oon-Ee :

...
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.

Yaro Kasear

12:28 a.m.

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?

Thorsten Töpper

12:45 a.m.

On Wed, 5 Jan 2011 18:28:42 -0600 Yaro Kasear 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

Thomas Bächler

9:50 a.m.

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.

Ng Oon-Ee

10:09 a.m.

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

Tom Gundersen

1:03 p.m.

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

Ulf Winkelvos

7 Jan 7 Jan

12:16 a.m.

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! :)

Karol Babioch

8 Jan 8 Jan

12:17 a.m.

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

Attila

7:27 a.m.

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

4886

Age (days ago)

4889

Last active (days ago)

Download

15 comments

14 participants

tags

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