Messages in this thread | | | Date | Mon, 8 Jul 2002 03:34:09 +0100 | From | Matthew Wilcox <> | Subject | Re: BKL removal |
| |
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. - 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/
| |