From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [TEST PATCH] xen/blkfront: use blk_rq_map_sg togenerate ring entries Date: Mon, 09 Feb 2009 09:35:47 -0800 Message-ID: <49906973.3030309@goop.org> References: <11773622.8411271233953279537.JavaMail.root@ouachita> <498CA8C8.6050808@goop.org> <49900AD1.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49900AD1.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Greg Harris , Xen-devel , Jens Axboe List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: > But isn't this just reducing the likelihood of hitting the problem? Without > understanding why the entry limit gets exceeded (and fixing that), the > potential for this to happen again is still there. > I had the same thought, but Jens says it fixes the real problem, so that satisfies me ;) Greg reported that simply decreasing the max segments to one less than the ring size was sufficient to clear up the symptoms, which indicates it was never submitting more than one extra segment. Jens writes: > The second problem is > that the block layer then appears to create one too many segments, but > from the dump it has rq->nr_phys_segments == > BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to > xen-blkfront not handling the merging on its own. It should check that > the new page doesn't form part of the previous page. which suggests that blkfront was omitting a merging check that driver should perform, results in this problem. I don't really understand why the upper layers can't do this merge check, but I'm sure Jens has a good reason. > Of course, the change made here has its own benefits, so I fully agree > it should be applied (though I wonder whether it's indeed a -stable > candidate). Well, it appears to be the proper fix to a real bug observed in the field, which makes it an ideal -stable candidate. J