From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Stodden Subject: Re: xen-blkfront: simplify resume? Date: Thu, 24 Mar 2011 14:46:54 -0700 Message-ID: <1301003214.11448.230.camel@agari.van.xensource.com> References: <1300959061.3507.1600.camel@ramone.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "rshriram@cs.ubc.ca" Cc: Xen Developers List-Id: xen-devel@lists.xenproject.org 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