Re: devfs: BKL *not* taken while opening devices

Russell King
2002-04-30T17:04:00Z

On Tue, Apr 30, 2002 at 09:42:32AM -0700, Dave Hansen wrote:
> I like the idea. But, while we're at it, does anyone have a good enough
> grasp of locking the the TTY layer that we can start peeling some of the
> BKL out of there? Somebody was doing tests over a serial console here
> and the lockmeter data showed horrible BKL contention and hold times.

I'm sure it isn't *that* bad for average workloads. Sure, if you hammer
the TTY layer madly to measure the BKL it will show up, but that isn't
an average workload.

I purposely didn't mention this in the previous mail. The tty code is
beyond any type of "peeling". The whole thing relies on the behaviour
of the BKL - in that when you sleep the BKL is released. Think about
someone opening /dev/cua0 while /dev/ttyS0 is trying to be opened, or
a hangup while a port is being opened, or... the list is endless.

It's not as simple as replacing the BKL with a semaphore or spinlock.

I've actually brought this up in passing with Alan back in October - his
feeling at the time was (iirc) that the effort required isn't worth the
rewards you'd get.

When I talked to Ted last, Ted was going to rewrite the whole thing to
get it into a reasonable shape, which included a BKL free tty layer.
I've not heard anything from Ted recently on this though.

However, being able to type on a laptop over a ssh connection to another
machine, and have everything freeze while the hard disk spins up for no
apparant reason (other than your typing) is an annoyance that I wouldn't
mind see "disappear".

--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux