public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nitin Gupta <ngupta@vflare.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Seth Jennings <sjenning@linux.vnet.ibm.com>,
	Jerome Marchand <jmarchan@redhat.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH 2/2] zram: allocate metadata when disksize is set up
Date: Mon, 26 Nov 2012 21:13:24 -0800	[thread overview]
Message-ID: <50B44BF4.30803@vflare.org> (raw)
In-Reply-To: <1353638567-3981-2-git-send-email-minchan@kernel.org>

On 11/22/2012 06:42 PM, Minchan Kim wrote:
> Lockdep complains about recursive deadlock of zram->init_lock.
> Because zram_init_device could be called in reclaim context and
> it requires a page with GFP_KERNEL.
>
> We can fix it via replacing GFP_KERNEL with GFP_NOIO.
> But more big problem is vzalloc in zram_init_device which calls GFP_KERNEL.
> We can change it with __vmalloc which can receive gfp_t.
> But still we have a problem. Although __vmalloc can handle gfp_t, it calls
> allocation of GFP_KERNEL. That's why I sent the patch.
> https://lkml.org/lkml/2012/4/23/77
>
> Yes. Fundamental problem is utter crap API vmalloc.
> If we can fix it, everyone would be happy. But life isn't simple
> like seeing my thread of the patch.
>
> So next option is to give up lazy initialization and initialize it at the
> very disksize setting time. But it makes unnecessary metadata waste until
> zram is really used. But let's think about it.
>
> 1) User of zram normally do mkfs.xxx or mkswap before using
>     the zram block device(ex, normally, do it at booting time)
>     It ends up allocating such metadata of zram before real usage so
>     benefit of lazy initialzation would be mitigated.
>
> 2) Some user want to use zram when memory pressure is high.(ie, load zram
>     dynamically, NOT booting time). It does make sense because people don't
>     want to waste memory until memory pressure is high(ie, where zram is really
>     helpful time). In this case, lazy initialzation could be failed easily
>     because we will use GFP_NOIO instead of GFP_KERNEL for avoiding deadlock.
>     So the benefit of lazy initialzation would be mitigated, too.
>
> 3) Metadata overhead is not critical and Nitin has a plan to diet it.
>     4K : 12 byte(64bit machine) -> 64G : 192M so 0.3% isn't big overhead
>     If insane user use such big zram device up to 20, it could consume 6% of ram
>     but efficieny of zram will cover the waste.
>
> So this patch gives up lazy initialization and instead we initialize metadata
> at disksize setting time.
>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
>   drivers/staging/zram/zram_drv.c   |   21 ++++-----------------
>   drivers/staging/zram/zram_sysfs.c |    1 +
>   2 files changed, 5 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index 9ef1eca..f364fb5 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -441,16 +441,13 @@ static void zram_make_request(struct request_queue *queue, struct bio *bio)
>   {
>   	struct zram *zram = queue->queuedata;
>
> -	if (unlikely(!zram->init_done) && zram_init_device(zram))
> -		goto error;
> -
>   	down_read(&zram->init_lock);
>   	if (unlikely(!zram->init_done))
> -		goto error_unlock;
> +		goto error;
>
>   	if (!valid_io_request(zram, bio)) {
>   		zram_stat64_inc(zram, &zram->stats.invalid_io);
> -		goto error_unlock;
> +		goto error;
>   	}
>
>   	__zram_make_request(zram, bio, bio_data_dir(bio));
> @@ -458,9 +455,8 @@ static void zram_make_request(struct request_queue *queue, struct bio *bio)
>
>   	return;
>
> -error_unlock:
> -	up_read(&zram->init_lock);
>   error:
> +	up_read(&zram->init_lock);
>   	bio_io_error(bio);
>   }
>
> @@ -509,19 +505,12 @@ void zram_reset_device(struct zram *zram)
>   	up_write(&zram->init_lock);
>   }
>
> +/* zram->init_lock should be hold */

s/hold/held

btw, shouldn't we also change GFP_KERNEL to GFP_NOIO in is_partial_io() 
case in both read/write handlers?

Rest of the patch looks good.


Thanks,
Nitin

>   int zram_init_device(struct zram *zram)
>   {
>   	int ret;
>   	size_t num_pages;
>
> -	down_write(&zram->init_lock);
> -	if (zram->init_done) {
> -		up_write(&zram->init_lock);
> -		return 0;
> -	}
> -
> -	BUG_ON(!zram->disksize);
> -
>   	if (zram->disksize > 2 * (totalram_pages << PAGE_SHIFT)) {
>   		pr_info(
>   		"There is little point creating a zram of greater than "
> @@ -570,7 +559,6 @@ int zram_init_device(struct zram *zram)
>   	}
>
>   	zram->init_done = 1;
> -	up_write(&zram->init_lock);
>
>   	pr_debug("Initialization done!\n");
>   	return 0;
> @@ -580,7 +568,6 @@ fail_no_table:
>   	zram->disksize = 0;
>   fail:
>   	__zram_reset_device(zram);
> -	up_write(&zram->init_lock);
>   	pr_err("Initialization failed: err=%d\n", ret);
>   	return ret;
>   }
> diff --git a/drivers/staging/zram/zram_sysfs.c b/drivers/staging/zram/zram_sysfs.c
> index 4143af9..369db12 100644
> --- a/drivers/staging/zram/zram_sysfs.c
> +++ b/drivers/staging/zram/zram_sysfs.c
> @@ -71,6 +71,7 @@ static ssize_t disksize_store(struct device *dev,
>
>   	zram->disksize = PAGE_ALIGN(disksize);
>   	set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
> +	zram_init_device(zram);
>   	up_write(&zram->init_lock);
>
>   	return len;
>


  reply	other threads:[~2012-11-27  5:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-23  2:42 [PATCH 1/2] zram: force disksize setting before using zram Minchan Kim
2012-11-23  2:42 ` [PATCH 2/2] zram: allocate metadata when disksize is set up Minchan Kim
2012-11-27  5:13   ` Nitin Gupta [this message]
2012-11-27 15:45     ` Jerome Marchand
2012-11-28  4:26       ` Minchan Kim
2012-11-28  4:22     ` Minchan Kim
2012-11-27  5:04 ` [PATCH 1/2] zram: force disksize setting before using zram Nitin Gupta
2012-11-28  4:20   ` Minchan 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=50B44BF4.30803@vflare.org \
    --to=ngupta@vflare.org \
    --cc=dan.magenheimer@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jmarchan@redhat.com \
    --cc=konrad@darnok.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=sjenning@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox