Messages in this thread | | | Date | Sun, 07 Jul 2002 19:52:34 -0700 | From | Dave Hansen <> | Subject | Re: 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. 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/
| |