Messages in this thread | | | Date | Wed, 17 Aug 2005 09:56:13 +0200 | From | Jens Axboe <> | Subject | Re: HDAPS, Need to park the head for real |
| |
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
- 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/
| |