From: Simon Jeons <simon.jeons@gmail.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
Luigi Semenzato <semenzato@google.com>,
linux-mm@kvack.org, Bob Liu <lliubbo@gmail.com>
Subject: Re: zram /proc/swaps accounting weirdness
Date: Sun, 17 Feb 2013 09:52:17 +0800 [thread overview]
Message-ID: <512037D1.2010907@gmail.com> (raw)
In-Reply-To: <9c96c9e7-4f6e-4e78-a207-009293c37b89@default>
On 12/12/2012 09:12 AM, Dan Magenheimer wrote:
>> From: Dan Magenheimer
>> Subject: RE: zram /proc/swaps accounting weirdness
>>
>>>> Can you explain how this could happen if num_writes never
>>>> exceeded 1863? This may be harmless in the case where
>>> Odd.
>>> I tried to reproduce it with zram and real swap device without
>>> zcache but failed. Does the problem happen only if enabling zcache
>>> together?
>> I also cannot reproduce it with only zram, without zcache.
>> I can only reproduce with zcache+zram. Since zcache will
>> only "fall through" to zram when the frontswap_store() call
>> in swap_writepage() fails, I wonder if in both cases swap_writepage()
>> is being called in large (e.g. SWAPFILE_CLUSTER-sized) blocks
>> of pages? When zram-only, the entire block of pages always gets
>> sent to zram, but with zcache only a small randomly-positioned
>> fraction fail frontswap_store(), but the SWAPFILE_CLUSTER-sized
>> blocks have already been pre-reserved on the swap device and
>> become only partially-filled?
> Urk. Never mind. My bad. When a swap page is compressed in
> zcache, it gets accounted in the swap subsystem as an "inuse"
Could you point out to me where add this count to swap subsystem?
> page for the backing swap device. (Frontswap provides a
> page-by-page "fronting store" for the swap device.) That explains
> why Used is so high for the "zram swap device" even though
> zram has only compressed a fraction of the pages... the
> remaining (much larger) number of pages have been compressed
> by/in zcache.
>
> Move along, there are no droids here. :-(
>
> Dan
>
> --
> 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=ilto:"dont@kvack.org"> email@kvack.org </a>
--
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>
next prev parent reply other threads:[~2013-02-17 1:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 23:57 zram /proc/swaps accounting weirdness Dan Magenheimer
2012-12-10 3:15 ` Bob Liu
2012-12-12 0:22 ` Dan Magenheimer
2012-12-11 6:26 ` Minchan Kim
2012-12-12 0:34 ` Dan Magenheimer
2012-12-12 1:12 ` Dan Magenheimer
2013-02-17 1:52 ` Simon Jeons [this message]
2013-02-18 17:54 ` Dan Magenheimer
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=512037D1.2010907@gmail.com \
--to=simon.jeons@gmail.com \
--cc=dan.magenheimer@oracle.com \
--cc=linux-mm@kvack.org \
--cc=lliubbo@gmail.com \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=semenzato@google.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.