All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Jerome Marchand <jmarchan@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Hugh Dickins <hughd@google.com>, Shaohua Li <shli@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Dan Streetman <ddstreet@ieee.org>,
	Nitin Gupta <ngupta@vflare.org>,
	Luigi Semenzato <semenzato@google.com>,
	juno.choi@lge.com
Subject: Re: [PATCH v1 4/5] zram: add swap full hint
Date: Thu, 25 Sep 2014 10:07:38 +0900	[thread overview]
Message-ID: <20140925010738.GC17364@bbox> (raw)
In-Reply-To: <5422DEDE.1060004@redhat.com>

On Wed, Sep 24, 2014 at 05:10:22PM +0200, Jerome Marchand wrote:
> On 09/23/2014 11:17 PM, Andrew Morton wrote:
> > On Tue, 23 Sep 2014 13:56:02 +0900 Minchan Kim <minchan@kernel.org> wrote:
> > 
> >>>
> >>>> +#define ZRAM_FULLNESS_PERCENT 80
> >>>
> >>> We've had problems in the past where 1% is just too large an increment
> >>> for large systems.
> >>
> >> So, do you want fullness_bytes like dirty_bytes?
> > 
> > Firstly I'd like you to think about whether we're ever likely to have
> > similar granularity problems with this tunable.  If not then forget
> > about it.
> > 
> > If yes then we should do something.  I don't like the "bytes" thing
> > much because it requires that the operator know the pool size
> > beforehand, and any time that changes, the "bytes" needs hanging too. 
> > Ratios are nice but percent is too coarse.  Maybe kernel should start
> > using "ppm" for ratios, parts per million.  hrm.
> 
> An other possibility is to use decimal fractions. AFAIK, lustre fs uses
> them already for its procfs entries.

Looks good to me. If anyone doesn't have better idea or objection,
I want to approach this way.

Thanks for the hint!

> 
> > 
> >>>> @@ -711,6 +732,7 @@ static void zram_reset_device(struct zram *zram, bool reset_capacity)
> >>>>  	down_write(&zram->init_lock);
> >>>>  
> >>>>  	zram->limit_pages = 0;
> >>>> +	atomic_set(&zram->alloc_fail, 0);
> >>>>  
> >>>>  	if (!init_done(zram)) {
> >>>>  		up_write(&zram->init_lock);
> >>>> @@ -944,6 +966,34 @@ static int zram_slot_free_notify(struct block_device *bdev,
> >>>>  	return 0;
> >>>>  }
> >>>>  
> >>>> +static int zram_full(struct block_device *bdev, void *arg)
> >>>
> >>> This could return a bool.  That implies that zram_swap_hint should
> >>> return bool too, but as we haven't been told what the zram_swap_hint
> >>> return value does, I'm a bit stumped.
> >>
> >> Hmm, currently, SWAP_FREE doesn't use return and SWAP_FULL uses return
> >> as bool so in the end, we can change it as bool but I want to remain it
> >> as int for the future. At least, we might use it as propagating error
> >> in future. Instead, I will use *arg to return the result instead of
> >> return val. But I'm not strong so if you want to remove return val,
> >> I will do it. For clarifictaion, please tell me again if you want.
> > 
> > I'm easy, as long as it makes sense, is understandable by people other
> > than he-who-wrote-it and doesn't use argument names such as "arg".
> > 
> > 
> 
> 



-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Jerome Marchand <jmarchan@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Hugh Dickins <hughd@google.com>, Shaohua Li <shli@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Dan Streetman <ddstreet@ieee.org>,
	Nitin Gupta <ngupta@vflare.org>,
	Luigi Semenzato <semenzato@google.com>,
	juno.choi@lge.com
Subject: Re: [PATCH v1 4/5] zram: add swap full hint
Date: Thu, 25 Sep 2014 10:07:38 +0900	[thread overview]
Message-ID: <20140925010738.GC17364@bbox> (raw)
In-Reply-To: <5422DEDE.1060004@redhat.com>

On Wed, Sep 24, 2014 at 05:10:22PM +0200, Jerome Marchand wrote:
> On 09/23/2014 11:17 PM, Andrew Morton wrote:
> > On Tue, 23 Sep 2014 13:56:02 +0900 Minchan Kim <minchan@kernel.org> wrote:
> > 
> >>>
> >>>> +#define ZRAM_FULLNESS_PERCENT 80
> >>>
> >>> We've had problems in the past where 1% is just too large an increment
> >>> for large systems.
> >>
> >> So, do you want fullness_bytes like dirty_bytes?
> > 
> > Firstly I'd like you to think about whether we're ever likely to have
> > similar granularity problems with this tunable.  If not then forget
> > about it.
> > 
> > If yes then we should do something.  I don't like the "bytes" thing
> > much because it requires that the operator know the pool size
> > beforehand, and any time that changes, the "bytes" needs hanging too. 
> > Ratios are nice but percent is too coarse.  Maybe kernel should start
> > using "ppm" for ratios, parts per million.  hrm.
> 
> An other possibility is to use decimal fractions. AFAIK, lustre fs uses
> them already for its procfs entries.

Looks good to me. If anyone doesn't have better idea or objection,
I want to approach this way.

Thanks for the hint!

> 
> > 
> >>>> @@ -711,6 +732,7 @@ static void zram_reset_device(struct zram *zram, bool reset_capacity)
> >>>>  	down_write(&zram->init_lock);
> >>>>  
> >>>>  	zram->limit_pages = 0;
> >>>> +	atomic_set(&zram->alloc_fail, 0);
> >>>>  
> >>>>  	if (!init_done(zram)) {
> >>>>  		up_write(&zram->init_lock);
> >>>> @@ -944,6 +966,34 @@ static int zram_slot_free_notify(struct block_device *bdev,
> >>>>  	return 0;
> >>>>  }
> >>>>  
> >>>> +static int zram_full(struct block_device *bdev, void *arg)
> >>>
> >>> This could return a bool.  That implies that zram_swap_hint should
> >>> return bool too, but as we haven't been told what the zram_swap_hint
> >>> return value does, I'm a bit stumped.
> >>
> >> Hmm, currently, SWAP_FREE doesn't use return and SWAP_FULL uses return
> >> as bool so in the end, we can change it as bool but I want to remain it
> >> as int for the future. At least, we might use it as propagating error
> >> in future. Instead, I will use *arg to return the result instead of
> >> return val. But I'm not strong so if you want to remove return val,
> >> I will do it. For clarifictaion, please tell me again if you want.
> > 
> > I'm easy, as long as it makes sense, is understandable by people other
> > than he-who-wrote-it and doesn't use argument names such as "arg".
> > 
> > 
> 
> 



-- 
Kind regards,
Minchan Kim

  reply	other threads:[~2014-09-25  1:06 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-22  0:03 [PATCH v1 0/5] stop anon reclaim when zram is full Minchan Kim
2014-09-22  0:03 ` Minchan Kim
2014-09-22  0:03 ` [PATCH v1 1/5] zram: generalize swap_slot_free_notify Minchan Kim
2014-09-22  0:03   ` Minchan Kim
2014-09-22 20:41   ` Andrew Morton
2014-09-22 20:41     ` Andrew Morton
2014-09-23  4:45     ` Minchan Kim
2014-09-23  4:45       ` Minchan Kim
2014-09-22  0:03 ` [PATCH v1 2/5] mm: add full variable in swap_info_struct Minchan Kim
2014-09-22  0:03   ` Minchan Kim
2014-09-22 20:45   ` Andrew Morton
2014-09-22 20:45     ` Andrew Morton
2014-09-23  4:45     ` Minchan Kim
2014-09-23  4:45       ` Minchan Kim
2014-09-24  2:53   ` Dan Streetman
2014-09-24  2:53     ` Dan Streetman
2014-09-24  7:57     ` Minchan Kim
2014-09-24  7:57       ` Minchan Kim
2014-09-22  0:03 ` [PATCH v1 3/5] mm: VM can be aware of zram fullness Minchan Kim
2014-09-22  0:03   ` Minchan Kim
2014-09-24 14:12   ` Dan Streetman
2014-09-24 14:12     ` Dan Streetman
2014-09-25  1:06     ` Minchan Kim
2014-09-25  1:06       ` Minchan Kim
2014-09-25  1:31       ` Dan Streetman
2014-09-25  1:31         ` Dan Streetman
2014-09-22  0:03 ` [PATCH v1 4/5] zram: add swap full hint Minchan Kim
2014-09-22  0:03   ` Minchan Kim
2014-09-22 21:11   ` Andrew Morton
2014-09-22 21:11     ` Andrew Morton
2014-09-23  4:56     ` Minchan Kim
2014-09-23  4:56       ` Minchan Kim
2014-09-23 21:17       ` Andrew Morton
2014-09-23 21:17         ` Andrew Morton
2014-09-24  7:57         ` Minchan Kim
2014-09-24  7:57           ` Minchan Kim
2014-09-24 15:10         ` Jerome Marchand
2014-09-25  1:07           ` Minchan Kim [this message]
2014-09-25  1:07             ` Minchan Kim
2014-09-24 14:01   ` Dan Streetman
2014-09-24 14:01     ` Dan Streetman
2014-09-25  1:02     ` Minchan Kim
2014-09-25  1:02       ` Minchan Kim
2014-09-25 15:52       ` Dan Streetman
2014-09-25 15:52         ` Dan Streetman
2014-10-06 23:36         ` Minchan Kim
2014-10-06 23:36           ` Minchan Kim
2014-10-06 23:46           ` Minchan Kim
2014-10-06 23:46             ` Minchan Kim
2014-10-08 18:29             ` Dan Streetman
2014-10-08 18:29               ` Dan Streetman
2014-09-22  0:03 ` [PATCH v1 5/5] zram: add fullness knob to control swap full Minchan Kim
2014-09-22  0:03   ` Minchan Kim
2014-09-22 21:17   ` Andrew Morton
2014-09-22 21:17     ` Andrew Morton
2014-09-23  4:57     ` Minchan Kim
2014-09-23  4:57       ` Minchan Kim
2014-12-02  3:04 ` [PATCH v1 0/5] stop anon reclaim when zram is full Minchan Kim
2014-12-02  3:04   ` 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=20140925010738.GC17364@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ddstreet@ieee.org \
    --cc=hughd@google.com \
    --cc=jmarchan@redhat.com \
    --cc=juno.choi@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ngupta@vflare.org \
    --cc=semenzato@google.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=shli@kernel.org \
    /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.