From: Minchan Kim <minchan@kernel.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Nitin Gupta <ngupta@vflare.org>,
Luigi Semenzato <semenzato@google.com>,
linux-mm@kvack.org
Subject: Re: zram /proc/swaps accounting weirdness
Date: Tue, 11 Dec 2012 15:26:01 +0900 [thread overview]
Message-ID: <20121211062601.GD22698@blaptop> (raw)
In-Reply-To: <c8728036-07da-49ce-b4cb-c3d800790b53@default>
Hi Dan,
On Fri, Dec 07, 2012 at 03:57:08PM -0800, Dan Magenheimer wrote:
> While playing around with zcache+zram (see separate thread),
> I was watching stats with "watch -d".
>
> It appears from the code that /sys/block/num_writes only
> increases, never decreases. In my test, num_writes got up
Never decreasement is natural.
> to 1863. /sys/block/disksize is 104857600.
>
> I have two swap disks, one zram (pri=60), one real (pri=-1),
> and as a I watched /proc/swaps, the "Used" field grew rapidly
> and reached the Size (102396k) of the zram swap, and then
> the second swap disk (a physical disk partition) started being
> used. Then for awhile, the Used field for both swap devices
> was changing (up and down).
>
> 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?
> the only swap on the system is zram; or may indicate a bug
> somewhere?
>
> It looks like num_writes is counting bio's not pages...
> which would imply the bio's are potentially quite large
> (and I'll guess they are of size SWAPFILE_CLUSTER which is
> defined to be 256). Do large clusters make sense with zram?
Swap_writepage handles a page and zram_make_request doesn't use
pluging mechanism of block I/O. So every request for swap-over-zram
is a bio and a page. So your problem might be a BUG.
>
> Late on a Friday so sorry if I am incomprehensible...
>
> P.S. The corresponding stat for zcache indicates that
> it failed 8852 stores, so I would have expected zram
> to deal with no more than 8852 compressions.
>
> --
> 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>
--
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>
next prev parent reply other threads:[~2012-12-11 6:26 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 [this message]
2012-12-12 0:34 ` Dan Magenheimer
2012-12-12 1:12 ` Dan Magenheimer
2013-02-17 1:52 ` Simon Jeons
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=20121211062601.GD22698@blaptop \
--to=minchan@kernel.org \
--cc=dan.magenheimer@oracle.com \
--cc=linux-mm@kvack.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.