I hate reeplying to myself, especially when it's to tell me that I'm an
idiot.. I just realised (i think) that what I suggest below is exactly
what you are doing...
julian
On Mon, 28 Jun 1999, Julian Elischer wrote:
>
>
> On Sun, 27 Jun 1999, Kirk McKusick wrote:
>
> > I see that Peter has already committed it.
> >
> > On the subject of BUF_KERNPROC, this must be done as I have coded
> > it, not later in biodone. The problem is when the filesystem does
> > a readahead. It starts the I/O on the buffer that it really wants,
> > then starts ASYNC reads on the readahead buffers. When it finishes
> > with the buffer that it wanted and the application enters the kernel
> > to get the next buffer, the filesystem will attempt to lock the
> > buffer on which it earlier initiated the read. If the I/O has not
> > yet finished one of two bad things will happen. If the lock is not
> > recursive, it will panic with `locking against myself' since it will
> > hold the lock from the time when it initiated the readahead. If
> > recursive locking is allowed, then it will get the buffer (since
> > it holds the exclusive lock) and use it before it has been filled.
> > So, it is semantically important that ASYNC read buffers be disowned
> > (i.e., given to the kernel) at the time they are created. That way,
> > only the kernel can access the buffer until the read I/O is done.
> > I agree that this code is ugly, but it is necessary.
> >
>
> One solution to the "locking against self" probelm with read-ahead
> buffers would be to give some other entity the ownership of the read-ahead.
> I would consider even having a separate ID for async operations
> (the asyncd kermnel thread?) Possibly they could simply be assigned to
> an existing PID (we have several to chose from .. pagedaemon,
> syncer or vmdaemon)
>
> I mean the requesting process isn't really actually requesting the
> lookahead, so it should be up to the entity that DID request it
> (the kernel?) to lock the buffers. I think that whenever you
> try make something appear as something that it is not you complicate
> the picture. In this case we are tryin g to make it look as if that process
> was responsible for the readahead requests, when in actual fact, it is
> another entity taking it upon itself to make that decision, and see where
> it gets us?
>
>
> julian
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
