From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [PATCH] remove use_sg_chaining Date: Sun, 20 Jan 2008 21:56:58 +0200 Message-ID: <4793A78A.6000604@panasas.com> References: <1200419579.9273.39.camel@localhost.localdomain> <47939E9B.9020906@panasas.com> <1200857062.3105.15.camel@localhost.localdomain> <20080120192942.GW6258@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from bzq-219-195-70.pop.bezeqint.net ([62.219.195.70]:54793 "EHLO bh-buildlin2.bhalevy.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755114AbYATT5Q (ORCPT ); Sun, 20 Jan 2008 14:57:16 -0500 In-Reply-To: <20080120192942.GW6258@kernel.dk> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Jens Axboe Cc: James Bottomley , linux-scsi On Sun, Jan 20 2008 at 21:29 +0200, Jens Axboe wrote: > On Sun, Jan 20 2008, James Bottomley wrote: >> On Sun, 2008-01-20 at 21:18 +0200, Boaz Harrosh wrote: >>> On Tue, Jan 15 2008 at 19:52 +0200, James Bottomley wrote: >>>> this patch depends on the sg branch of the block tree >>>> >>>> James >>>> >>>> --- >>>> From: James Bottomley >>>> Date: Tue, 15 Jan 2008 11:11:46 -0600 >>>> Subject: remove use_sg_chaining >>>> >>>> With the sg table code, every SCSI driver is now either chain capable >>>> or broken, so there's no need to have a check in the host template. >>>> >>>> Also tidy up the code by moving the scatterlist size defines into the >>>> SCSI includes and permit the last entry of the scatterlist pools not >>>> to be a power of two. >>>> --- >>> I have a theoretical problem that BUGed me from the beginning. >>> >>> Could it happen that a memory critical IO, (that is needed to free >>> memory), be collected into an sg-chained large IO, and the allocation >>> of the multiple sg-pool-allocations fail, thous dead locking on >>> out-of-memory? Is there a mechanism in place that will split large IO's >>> into smaller chunks in the event of out-of-memory condition in prep_fn? >>> >>> Is it possible to call blk_rq_map_sg() with less then what is present >>> at request to only map the starting portion? >> Obviously, that's why I was worrying about mempool size and default >> blocks a while ago. >> >> However, the deadlock only occurs if the device is swap or backing a >> filesystem with memory mapped files. The use cases for this are really >> tapes and other entities that need huge buffers. That's why we're >> keeping the system sector size at 1024 unless you alter it through sysfs >> (here gun, there foot ...) > > Alternatively (and much safer, imho), we allow blk_rq_map_sg() return > smaller than nr_phys_segments and just ensure that the request is > continued nicely through the normal 'request if residual' logic. > Thats a grate Idea. I will Q it on my todo list. Thanks Boaz