RE: zram /proc/swaps accounting weirdness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Minchan Kim [mailto:minchan@xxxxxxxxxx]
> Subject: Re: zram /proc/swaps accounting weirdness
> 
> 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.

Agreed.
 
> > 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?

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?

Thanks,
Dan

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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]