[lkml]   [2002]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BKL removal
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.

> 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.108 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site