All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Liu <bob.liu@oracle.com>
To: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Bob Liu <lliubbo@gmail.com>,
	linux-mm@kvack.org, akpm@linux-foundation.org, ngupta@vflare.org,
	minchan@kernel.org, konrad.wilk@oracle.com,
	dan.magenheimer@oracle.com, rcj@linux.vnet.ibm.com,
	mgorman@suse.de, riel@redhat.com, dave@sr71.net,
	hughd@google.com
Subject: Re: [RFC PATCH] zswap: add zswap shrinker
Date: Thu, 23 May 2013 09:56:35 +0800	[thread overview]
Message-ID: <519D7753.2070801@oracle.com> (raw)
In-Reply-To: <20130522140815.GA3589@cerebellum>


On 05/22/2013 10:08 PM, Seth Jennings wrote:
> On Wed, May 22, 2013 at 12:03:03PM +0800, Bob Liu wrote:
>>
>> On 05/22/2013 02:57 AM, Seth Jennings wrote:
>>> On Tue, May 21, 2013 at 02:26:07PM +0800, Bob Liu wrote:
>>>> In my understanding, currenlty zswap have a few problems.
>>>> 1. The zswap pool size is 20% of total memory that's too random and once it
>>>> gets full the performance may even worse because everytime pageout() an anon
>>>> page two disk-io write ops may happend instead of one.
>>>
>>> Just to clarify, 20% is a default maximum amount that zswap can occupy.
>>>
>>> Also, in the steady over-the-limit state, the average number of writebacks is
>>> equal to the number of pages coming into zswap.  The description above makes it
>>> sound like there is a reclaim amplification effect (two writebacks per zswap
>>> store) when, on average, there is none. The 2:1 effect only happens on one or
>>> two store operations right after the pool becomes full.
>>
>> I don't think it only happens on one or two store operations.
>>
>> When the system enter a situation or run a workload which have many anon
>> pages, the zswap pool will be full easily and most of the time.
> 
> I think the part missing here is the just because a page is reclaimed on a
> particular store because we are over the zswap limit doesn't necessarily mean
> that page will be reallocated to the pool on the next zbud_alloc().  The
> reclaimed page is only reallocated if there is no unbuddied page in the pool
> with enough free space to hold the requested allocation.
> 
> In the case that the reclaimed page is not reallocated to the pool, we will be
> under the pool limit on the next zswap store and not do reclaim.
> 

That's true, I see your idea here.
But it's probably that there will be no suitable unbuddied pages in the
pool.
Mel gave a very good and detail example about nchunks in thread:
Re: [PATCHv11 2/4] zbud: add to mm/

-- 
Regards,
-Bob

--
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>

      reply	other threads:[~2013-05-23  1:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21  6:26 [RFC PATCH] zswap: add zswap shrinker Bob Liu
2013-05-21 18:57 ` Seth Jennings
2013-05-22  4:03   ` Bob Liu
2013-05-22  6:05     ` Bob Liu
2013-05-22 14:08     ` Seth Jennings
2013-05-23  1:56       ` Bob Liu [this message]

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=519D7753.2070801@oracle.com \
    --to=bob.liu@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.magenheimer@oracle.com \
    --cc=dave@sr71.net \
    --cc=hughd@google.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=lliubbo@gmail.com \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=rcj@linux.vnet.ibm.com \
    --cc=riel@redhat.com \
    --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 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.