Re: HDAPS, Need to park the head for real

[Jens Axboe <axboe@suse.de>]

On Wed, Aug 17 2005, Avi Kivity wrote:
> Jens Axboe wrote:
> 
> >Ok, I'll give you some hints to get you started... What you really want
> >to do, is:
> >
> >- Insert a park request at the front of the queue
> >- On completion callback on that request, freeze the block queue and
> > schedule it for unfreeze after a given time
> >
> > 
> >
> how will this interact with command queuing? there is a danger from both 
> commands previously queued but not yet completed, and commands that are 
> queued after the park request. or is the park request a barrier?

It doesn't interact with queueing, it doesn't matter what else is in the
queue. The park itself is not a barrier, since it should be placed as
next-to-execute at the front of the queue. Non-fs requests are never
reordered once inserted (since sorting on them doesn't make sense, the
io scheduler doesn't know what they are). Since the queue will not be
processed after the park has completed (it is frozen). So if the queue
currently looks like this:

[R0] <-> R1 <-> R2 <-> W1 <-> R3 <-> W2

(R is read, W is write, R0 is currently being processed), when you issue
the park the queue will look like:

[R0] <-> PARK <-> R1 <-> R2 <-> W1 <-> R3 <-> W2

Read completes, PARK will now be executed. While this happens, two more
writes are inserted somewhere in the queue. If successful, queue is
frozen in this state:

[] <-> R1 <-> W4 <-> R2 <-> W1 <-> W3 <-> R3 <-> W2

When the queue is thawed, R1 will be sent next.

-- 
Jens Axboe