All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Marchand <jmarchan@redhat.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
	linux-kernel@vger.kernel.org, Joonsoo Kim <js1304@gmail.com>
Subject: Re: [PATCH v2] zram: support REQ_DISCARD
Date: Wed, 26 Feb 2014 15:06:35 +0100	[thread overview]
Message-ID: <530DF4EB.90605@redhat.com> (raw)
In-Reply-To: <20140226135741.GB2217@swordfish.minsk.epam.com>

On 02/26/2014 02:57 PM, Sergey Senozhatsky wrote:
> On (02/26/14 14:44), Jerome Marchand wrote:
>> On 02/26/2014 02:16 PM, Sergey Senozhatsky wrote:
>>> Hello,
>>>
>>> On (02/26/14 14:23), Joonsoo Kim wrote:
>>>> zram is ram based block device and can be used by backend of filesystem.
>>>> When filesystem deletes a file, it normally doesn't do anything on data
>>>> block of that file. It just marks on metadata of that file. This behavior
>>>> has no problem on disk based block device, but has problems on ram based
>>>> block device, since we can't free memory used for data block. To overcome
>>>> this disadvantage, there is REQ_DISCARD functionality. If block device
>>>> support REQ_DISCARD and filesystem is mounted with discard option,
>>>> filesystem sends REQ_DISCARD to block device whenever some data blocks are
>>>> discarded. All we have to do is to handle this request.
>>>>
>>>> This patch implements to flag up QUEUE_FLAG_DISCARD and handle this
>>>> REQ_DISCARD request. With it, we can free memory used by zram if it isn't
>>>> used.
>>>>
>>>> v2: handle unaligned case commented by Jerome
>>>>
>>>> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>>>>
>>>> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
>>>> index 5ec61be..5364c1e 100644
>>>> --- a/drivers/block/zram/zram_drv.c
>>>> +++ b/drivers/block/zram/zram_drv.c
>>>> @@ -501,6 +501,36 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
>>>>  	return ret;
>>>>  }
>>>>  
>>>> +static void zram_bio_discard(struct zram *zram, struct bio *bio)
>>>> +{
>>>> +	u32 index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
>>>> +	size_t n = bio->bi_iter.bi_size;
>>>> +	size_t misalign;
>>>> +
>>>> +	/*
>>>> +	 * On some arch, logical block (4096) aligned request couldn't be
>>>> +	 * aligned to PAGE_SIZE, since their PAGE_SIZE aren't 4096.
>>>> +	 * Therefore we should handle this misaligned case here.
>>>> +	 */
>>>> +	misalign = (bio->bi_iter.bi_sector &
>>>> +			(SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;
>>>> +	if (misalign) {
>>>> +		if (n < misalign)
>>>> +			return;
>>>> +
>>>> +		n -= misalign;
>>>> +		index++;
>>>> +	}
>>>> +
>>>> +	while (n >= PAGE_SIZE) {
>>>> +		write_lock(&zram->meta->tb_lock);
>>>> +		zram_free_page(zram, index);
>>>> +		write_unlock(&zram->meta->tb_lock);
>>>> +		index++;
>>>> +		n -= PAGE_SIZE;
>>>> +	}
>>>> +}
>>>> +
>>>
>>> a side note, do we need zram_bio_discard() function? I mean, can we handle
>>> discard request in zram_bvec_rw(), where we already know index, etc. (passed
>>> from __zram_make_request())?
>>>
>>
>> We'd still have to make sure not to discard pages that are still partially
>> used, but it might simplify the code: __zram_make_request() already takes
>> care of splitting the request.
>>
>>> for example:
>>>
>>> @@ -510,6 +510,11 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
>>>                 ret = zram_bvec_write(zram, bvec, index, offset);
>>>         }
>>>  
>>> +       if (unlikely(bio->bi_rw & REQ_DISCARD)) {
>>
>> +		if (!is_partial_io(bvec) {
>>
>>> +               write_lock(&zram->meta->tb_lock);
>>> +               zram_free_page(zram, index);
>>> +               write_unlock(&zram->meta->tb_lock);
>>
>> +		}
>>
>> Also this code might still call zram_bvec_read() and increase num_reads
>> for discard request: I guess bio_data_dir(bio) == READ == 0 in this case.
>>
>> Btw, why __zram_make_request() has an that rw argument? All the information
>> it needs is passed by the bio argument already. I kind of recollect to have
>> seen a cleanup patch that get rid of it or is it just my imagination?
>>
> 
> it doesn't. cleanup patch 'do not pass rw argument to __zram_make_request()'
> is in linux-next.
> 

You're right. I must be blind since there is an exemple of __zram_make_request()
without this argument just a few line below.

> 	-ss
> 
>> Jerome
>>
>>> +       }
>>>         return ret;
>>>  }
>>>
>>> 	-ss
>>>
>>>>  static void zram_reset_device(struct zram *zram, bool reset_capacity)
>>>>  {
>>>>  	size_t index;
>>>> @@ -618,6 +648,12 @@ static void __zram_make_request(struct zram *zram, struct bio *bio)

I need to open my eyes.

Jerome

>>>>  	struct bio_vec bvec;
>>>>  	struct bvec_iter iter;
>>>>  
>>>> +	if (unlikely(bio->bi_rw & REQ_DISCARD)) {
>>>> +		zram_bio_discard(zram, bio);
>>>> +		bio_endio(bio, 0);
>>>> +		return;
>>>> +	}
>>>> +
>>>>  	index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
>>>>  	offset = (bio->bi_iter.bi_sector &
>>>>  		  (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;
>>>> @@ -784,6 +820,10 @@ static int create_device(struct zram *zram, int device_id)
>>>>  					ZRAM_LOGICAL_BLOCK_SIZE);
>>>>  	blk_queue_io_min(zram->disk->queue, PAGE_SIZE);
>>>>  	blk_queue_io_opt(zram->disk->queue, PAGE_SIZE);
>>>> +	zram->disk->queue->limits.discard_granularity = PAGE_SIZE;
>>>> +	zram->disk->queue->limits.max_discard_sectors = UINT_MAX;
>>>> +	zram->disk->queue->limits.discard_zeroes_data = 1;
>>>> +	queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, zram->disk->queue);
>>>>  
>>>>  	add_disk(zram->disk);
>>>>  
>>>> -- 
>>>> 1.7.9.5
>>>>
>>


  reply	other threads:[~2014-02-26 14:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26  5:23 [PATCH v2] zram: support REQ_DISCARD Joonsoo Kim
2014-02-26  8:07 ` Minchan Kim
2014-02-28 15:24   ` Joonsoo Kim
2014-03-06  8:24     ` Minchan Kim
2014-02-26 13:16 ` Sergey Senozhatsky
2014-02-26 13:44   ` Jerome Marchand
2014-02-26 13:57     ` Sergey Senozhatsky
2014-02-26 14:06       ` Jerome Marchand [this message]
2014-02-28 15:20         ` Joonsoo Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=530DF4EB.90605@redhat.com \
    --to=jmarchan@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=js1304@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.