Re: BKL removal

[Matthew Wilcox]

On Sun, Jul 07, 2002 at 04:45:21PM -0700, Dave Hansen wrote:
> Don't forget that the BKL is released on sleep.  It is OK to hold it
> over a schedule()able operation.  If I remember right, there is no 
> real protection needed for the file->private_data either because there 
> is 1 and only 1 struct file per open, and the data is not shared among 
> struct files.

one struct file per open(), yes.  however, fork() shares a struct file,
as does unix domain fd passing.  so we need protection between different
processes.  there's some pretty good reasons to want to use a semaphore
to protect the struct file (see fasync code.. bleugh).

however, our semaphores currently suck.  they attempt to acquire the sem
immediately and if they fail go straight to sleep.  schimmel (i think..)
suggests spinning for a certain number of iterations before sleeping.
the great thing is, it's all out of line slowpath code so the additional
size shouldn't matter.  obviously this is SMP-only, and it does require
someone to do it who can measure the difference (and figure out how may
iterations to spin for before sleeping).

i was wondering if this might be a project you'd like to take on which
would upset far fewer people and perhaps yield greater advantage.

-- 
Revolutions do not require corporate support.