writeCallback

uprugist

unread,

May 9, 2005, 12:06:09 AM5/9/05

to

Hello,
I am looking at the code and not understanding - why does it block the
process only if the index is last one to read. So if we are reading a
block that is not the last one according to writeCallback if our
request to buffer cache fails and returns null, we just happily return
from callback? That seems oddly wrong. Am I missing something
fundamental?

uprugist

unread,

May 9, 2005, 12:10:08 AM5/9/05

to

Eric Tschetter

unread,

May 9, 2005, 1:46:52 AM5/9/05

to

Writes are Reads could access multiple blocks in the same write/read.

--Eric

sg

unread,

May 9, 2005, 9:08:46 PM5/9/05

to

I'm still not understanding your answer. So in the case that the read/write
call accesses multiple blocks, writecallback (for example) will be called
for each block. Why is it that sched.proc_block() is only called on the
last of those blocks?
Thanks for your patience,
Sam
"Eric Tschetter" <er...@mail.utexas.edu> wrote in message
news:d5mtgj$cjb$1...@news.cs.utexas.edu...

Mohnish Rao

unread,

May 9, 2005, 9:50:25 PM5/9/05

to

When you read a file, you want to block until the entire file has been read
and then unblock. You don't want to block for one data block and then
unblock, then block for the next data block and unblock etc...

"sg" <s...@sg.sg> wrote in message news:d5p1j7$lej$1...@geraldo.cc.utexas.edu...

Adrian Kubala

unread,

May 9, 2005, 10:22:19 PM5/9/05

to

sg <s...@sg.sg> schrieb:

> I'm still not understanding your answer. So in the case that the read/write
> call accesses multiple blocks, writecallback (for example) will be called
> for each block. Why is it that sched.proc_block() is only called on the
> last of those blocks?

I don't understand it either... the theory seems to be that block and
unblock should be called once for the entire write (that makes sense),
but it *looks* like if *some* pages block but the last one doesn't, the
process won't be blocked/unblocked. Maybe somebody who used that method
as written can test it and confirm or deny.

sg

unread,

May 9, 2005, 11:45:15 PM5/9/05

to

Right. So wouldn't it make sense to call proc_block() in the first part of
the ST_WRITE_READBLOCK case for the first block that doesn't hit the cache
and call proc_unblock() as it is now coded? Granted you would have to
actually check to make sure that a process is actually on the block_q in
your scheduler code before trying to remove it in the case that all of the
pages hit the cache but that should be done anyway. Am I on the right track
here?
"Adrian Kubala" <adria...@sixfingeredman.net> wrote in message
news:slrnd806mr.4o...@sixfingeredman.net...

Adrian Kubala

unread,

May 10, 2005, 1:04:28 AM5/10/05

to

sg <s...@sg.sg> schrieb:

> Right. So wouldn't it make sense to call proc_block() in the first part of
> the ST_WRITE_READBLOCK case for the first block that doesn't hit the cache
> and call proc_unblock() as it is now coded?

Close -- I think you'd have to proc_unblock for the last block that
doesn't hit the cache (not the last block requested, as it is now
coded).

sg

unread,

May 10, 2005, 1:35:21 AM5/10/05

to

How do you tell that the current block request that was just satisfied will
be the last request that doesn't hit the cache? You don't really know what
will be in the cache until you have finsihed servicing that request right?

"Adrian Kubala" <adria...@sixfingeredman.net> wrote in message

news:slrnd80g6s.6b...@sixfingeredman.net...

Adrian Kubala

unread,

May 10, 2005, 1:44:19 AM5/10/05

to

sg <s...@sg.sg> schrieb:

> How do you tell that the current block request that was just satisfied will
> be the last request that doesn't hit the cache? You don't really know what
> will be in the cache until you have finsihed servicing that request right?

I kept count of how many requests have been satisfied for the read, and
when the last one is satisfied (not necessarily the last block to be
requested, but the last one to be satisfied), then I unblock. I'm sure
there're other ways to do it.