Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751564AbdDCGMd convert rfc822-to-8bit (ORCPT ); Mon, 3 Apr 2017 02:12:33 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:42810 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751141AbdDCGMc (ORCPT ); Mon, 3 Apr 2017 02:12:32 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.249.25 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Mon, 3 Apr 2017 15:12:27 +0900 From: Minchan Kim To: Mika =?iso-8859-1?Q?Penttil=E4?= CC: Andrew Morton , , Sergey Senozhatsky , Subject: Re: [PATCH 2/5] zram: partial IO refactoring Message-ID: <20170403061227.GA7681@bbox> References: <1491196653-7388-1-git-send-email-minchan@kernel.org> <1491196653-7388-3-git-send-email-minchan@kernel.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB04/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/04/03 15:12:28, Serialize by Router on LGEKRMHUB04/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/04/03 15:12:28 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1950 Lines: 56 Hi Mika, On Mon, Apr 03, 2017 at 08:52:33AM +0300, Mika Penttil? wrote: > > Hi! > > On 04/03/2017 08:17 AM, Minchan Kim wrote: > > For architecture(PAGE_SIZE > 4K), zram have supported partial IO. > > However, the mixed code for handling normal/partial IO is too mess, > > error-prone to modify IO handler functions with upcoming feature > > so this patch aims for cleaning up zram's IO handling functions. > > > > Signed-off-by: Minchan Kim > > --- > > drivers/block/zram/zram_drv.c | 333 +++++++++++++++++++++++------------------- > > 1 file changed, 184 insertions(+), 149 deletions(-) > > > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > > index 28c2836f8c96..7938f4b98b01 100644 > > --- a/drivers/block/zram/zram_drv.c > > +++ b/drivers/block/zram/zram_drv.c > > @@ -45,6 +45,8 @@ static const char *default_compressor = "lzo"; > > /* Module params (documentation at end) */ > > static unsigned int num_devices = 1; > > > > +static void zram_free_page(struct zram *zram, size_t index); > > + > > static inline bool init_done(struct zram *zram) > > { > > return zram->disksize; > > @@ -98,10 +100,17 @@ static void zram_set_obj_size(struct zram_meta *meta, > > meta->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size; > > } > > > > +#if PAGE_SIZE != 4096 > > static inline bool is_partial_io(struct bio_vec *bvec) > > { > > return bvec->bv_len != PAGE_SIZE; > > } > > +#else > > For page size of 4096 bv_len can still be < 4096 and partial pages should be supported > (uncompress before write etc). ? zram declares this. #define ZRAM_LOGICAL_BLOCK_SIZE (1<<12) blk_queue_physical_block_size(zram->disk->queue, PAGE_SIZE); blk_queue_logical_block_size(zram->disk->queue, ZRAM_LOGICAL_BLOCK_SIZE); So, I thought there is no such partial IO in 4096 page architecture. Am I missing something? Could you tell the scenario if it happens? Thanks!