On Thu, 2011-03-24 at 16:08 -0400, Shriram Rajagopalan wrote:
> I wonder, should we just take the pending request and push it
> back onto
> the request_queue (with a blk_requeue_request)?
>
> Different from the present code, this should also help
> preserve original
> submit order if done right. (Don't panic, not like it matters
> a lot
> anymore since the block barrier flags are gone.)
>
> If we want to keep the shadow copy, let's do so with a
> prep_rq_fn. It
> gets called before the request gets pulled off the queue.
> Looks nicer,
> and one can arrange things so it only gets called once.
>
> Counter opinions?
>
> A bit confused. If things were as simple as stuffing the pending reqs
> back
> into the req_queue, why resort to shadowing the requests in the first
> place?
You're not confused at all. I wasn't sure yet if pushing back requests
and just redoing them might be flawed somehow. Then just checking out
what the options would be if the shadow is still wanted.
One tiny little detail I forgot to consider was that the grant entries
need to flip MFNs. So R/W requests still need fixup before requeuing.
Also, we still have to tear them down after completion :>.
So, keeping the entire request struct for reference, instead of growing
a custom vector type, isn't so bad.
One pretty way to fix up segments is to blk_unprep_request (tearing them
down), and then push the it back. They'll be reprepped (ouh, I love that
word) before they return.
Or keep the old way around, i.e. just a row update). Unprep might drop
some extra lines, and performance is a no-brainer. I'll guess I'll just
try it out.
> (esp, with the blk barrier flags gone)
Well yeah, on newer kernels. But deliberately breaking it in subtle
little ways doesn't look so smart either.
And despite the fact that FSes seem to have been draining quite eagerly
for quite some time, I think I've seen post-FLUSH+FUA patches for jbd2
adding missing drains where it still used to rely on queue order. No
idea sure if those missed in stable kernels.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home