Re: BKL removal

From: Dave Hansen (haveblue@us.ibm.com)
Date: Sun Jul 07 2002 - 21:52:34 EST


Matthew Wilcox wrote:
> 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).

But, this at least means that we don't need to protect
file->private_data during the open itself, right?

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

Well, I certainly have the hardware to measure the difference. But, I
seem to remember several conversations in the past where people didn't
like this behavior.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=linux.kernel.3C62DABA.3020906%40us.ibm.com

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

Yes, something less controvertial, please! A dumb implementation
would be pretty easy on top of current semaphores, but I think it was
already done (see above).

-- 
Dave Hansen
haveblue@us.ibm.com

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:18 EST