On 17 August 2016 at 18:02, Pekka Enberg <penberg@xxxxxxxxxx> wrote: > On Wed, Aug 17, 2016 at 1:18 PM, Srividya Desireddy > <srividya.dr@xxxxxxxxxxx> wrote: >>> This patch adds a check in zswap_frontswap_store() to identify zero-filled >>> page before compression of the page. If the page is a zero-filled page, set >>> zswap_entry.zeroflag and skip the compression of the page and alloction >>> of memory in zpool. In zswap_frontswap_load(), check if the zeroflag is >>> set for the page in zswap_entry. If the flag is set, memset the page with >>> zero. This saves the decompression time during load. >>> >>> The overall overhead caused due to zero-filled page check is very minimal >>> when compared to the time saved by avoiding compression and allocation in >>> case of zero-filled pages. The load time of a zero-filled page is reduced >>> by 80% when compared to baseline. > > On Wed, Aug 17, 2016 at 3:25 PM, Pekka Enberg <penberg@xxxxxxxxxx> wrote: >> AFAICT, that's an overall improvement only if there are a lot of >> zero-filled pages because it's just overhead for pages that we *need* >> to compress, no? So I suppose the question is, are there a lot of >> zero-filled pages that we need to swap and why is that the case? > > I suppose reading your cover letter would have been helpful before > sending out my email: > > "Experiments have shown that around 10-15% of pages stored in zswap are > duplicates which results in 10-12% more RAM required to store these > duplicate compressed pages." > > But I still don't understand why we have zero-filled pages that we are > swapping out. > > - Pekka Zero-filled pages exists in memory because applications may be initializing the allocated pages with zeros and not using them; or the actual content written to the memory pages during execution itself is zeros. The existing page reclamation path in kernel does not check for zero-filled pages in the anonymous LRU lists before swapping out. - Srividya
