RE: zram /proc/swaps accounting weirdness

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

 



> 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"
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@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]