All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] zram: introduce per-device debug_stat sysfs node
Date: Sat, 14 May 2016 08:05:46 +0900	[thread overview]
Message-ID: <20160513230546.GA26763@bbox> (raw)
In-Reply-To: <20160513080643.GE615@swordfish>

Hello Sergey,

On Fri, May 13, 2016 at 05:06:43PM +0900, Sergey Senozhatsky wrote:
> On (05/13/16 16:20), Minchan Kim wrote:
> > > > > @@ -737,12 +737,12 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
> > > > >  		zcomp_strm_release(zram->comp, zstrm);
> > > > >  		zstrm = NULL;
> > > > >  
> > > > > -		atomic64_inc(&zram->stats.num_recompress);
> > > > > -
> > > > >  		handle = zs_malloc(meta->mem_pool, clen,
> > > > >  				GFP_NOIO | __GFP_HIGHMEM);
> > > > > -		if (handle)
> > > > > +		if (handle) {
> > > > > +			atomic64_inc(&zram->stats.num_recompress);
> > > > >  			goto compress_again;
> > > > > +		}
> 
> 
> just a small note:
> 
> > Although 2 is smaller, your patch just accounts only direct reclaim but my
> > suggestion can count both 1 and 2 so isn't it better?
> 
> no, my patch accounts 1) and 2) as well. the only difference is that my
> patch accounts second zs_malloc() call _EVEN_ if it has failed and we
> jumped to goto err (because we still could have done reclaim). the new
> version would account second zs_malloc() _ONLY_ if it has succeeded, and
> thus possibly reclaim would not be accounted.
> 
> 
> recompress:
> 	compress
> 	handle = zs_malloc FAST PATH
> 
> 	if (!handle) {
> 		release stream
> 		handle = zs_malloc SLOW PATH
> 
> 		<< my patch accounts SLOW PATH here >>
> 
> 		if (handle) {
> 			num_recompress++  << NEW version accounts it here, only it was OK >>
> 			goto recompress;
> 		}
> 
> 		goto err;    << SLOW PATH is not accounted if SLOW PATH was unsuccessful
> 	}
> 

I got your point. You want to account every slow path and change
the naming from num_recompress to something to show that slow path.
Sorry for catching your point too late. And I absolutely agree with you.
I want to name it with 'writestall' like MM's allocstall. :)
Now I saw you sent new version but I like your suggestion more.

I will send new verion by hand :)
Thanks for the arguing. It was worth!

--
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: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH] zram: introduce per-device debug_stat sysfs node
Date: Sat, 14 May 2016 08:05:46 +0900	[thread overview]
Message-ID: <20160513230546.GA26763@bbox> (raw)
In-Reply-To: <20160513080643.GE615@swordfish>

Hello Sergey,

On Fri, May 13, 2016 at 05:06:43PM +0900, Sergey Senozhatsky wrote:
> On (05/13/16 16:20), Minchan Kim wrote:
> > > > > @@ -737,12 +737,12 @@ static int zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 index,
> > > > >  		zcomp_strm_release(zram->comp, zstrm);
> > > > >  		zstrm = NULL;
> > > > >  
> > > > > -		atomic64_inc(&zram->stats.num_recompress);
> > > > > -
> > > > >  		handle = zs_malloc(meta->mem_pool, clen,
> > > > >  				GFP_NOIO | __GFP_HIGHMEM);
> > > > > -		if (handle)
> > > > > +		if (handle) {
> > > > > +			atomic64_inc(&zram->stats.num_recompress);
> > > > >  			goto compress_again;
> > > > > +		}
> 
> 
> just a small note:
> 
> > Although 2 is smaller, your patch just accounts only direct reclaim but my
> > suggestion can count both 1 and 2 so isn't it better?
> 
> no, my patch accounts 1) and 2) as well. the only difference is that my
> patch accounts second zs_malloc() call _EVEN_ if it has failed and we
> jumped to goto err (because we still could have done reclaim). the new
> version would account second zs_malloc() _ONLY_ if it has succeeded, and
> thus possibly reclaim would not be accounted.
> 
> 
> recompress:
> 	compress
> 	handle = zs_malloc FAST PATH
> 
> 	if (!handle) {
> 		release stream
> 		handle = zs_malloc SLOW PATH
> 
> 		<< my patch accounts SLOW PATH here >>
> 
> 		if (handle) {
> 			num_recompress++  << NEW version accounts it here, only it was OK >>
> 			goto recompress;
> 		}
> 
> 		goto err;    << SLOW PATH is not accounted if SLOW PATH was unsuccessful
> 	}
> 

I got your point. You want to account every slow path and change
the naming from num_recompress to something to show that slow path.
Sorry for catching your point too late. And I absolutely agree with you.
I want to name it with 'writestall' like MM's allocstall. :)
Now I saw you sent new version but I like your suggestion more.

I will send new verion by hand :)
Thanks for the arguing. It was worth!

  reply	other threads:[~2016-05-13 23:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 13:45 [PATCH] zram: introduce per-device debug_stat sysfs node Sergey Senozhatsky
2016-05-11 13:45 ` Sergey Senozhatsky
2016-05-12 23:41 ` Minchan Kim
2016-05-12 23:41   ` Minchan Kim
2016-05-13  1:09   ` Sergey Senozhatsky
2016-05-13  1:09     ` Sergey Senozhatsky
2016-05-13  6:23     ` Minchan Kim
2016-05-13  6:23       ` Minchan Kim
2016-05-13  6:58       ` Sergey Senozhatsky
2016-05-13  6:58         ` Sergey Senozhatsky
2016-05-13  7:05         ` Sergey Senozhatsky
2016-05-13  7:05           ` Sergey Senozhatsky
2016-05-13  7:20           ` Minchan Kim
2016-05-13  7:20             ` Minchan Kim
2016-05-13  7:41             ` Sergey Senozhatsky
2016-05-13  7:41               ` Sergey Senozhatsky
2016-05-13  8:06             ` Sergey Senozhatsky
2016-05-13  8:06               ` Sergey Senozhatsky
2016-05-13 23:05               ` Minchan Kim [this message]
2016-05-13 23:05                 ` Minchan Kim
2016-05-14  3:37                 ` Sergey Senozhatsky
2016-05-14  3:37                   ` Sergey Senozhatsky
  -- strict thread matches above, loose matches on Subject: below --
2016-05-13 13:03 Sergey Senozhatsky
2016-05-13 23:08 ` Minchan Kim
2016-05-14  3:38   ` Sergey Senozhatsky

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=20160513230546.GA26763@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --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.