RE: zram /proc/swaps accounting weirdness

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

 



> From: Simon Jeons [mailto:simon.jeons@xxxxxxxxx]
> Subject: Re: zram /proc/swaps accounting weirdness
> 
> 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?

The swap subsystem doesn't know whether the page is
held in zcache or has been written to the swap disk,
only that one of these happened.  So si->inuse_pages gets
incremented either way.

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