Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755550AbaAMRDa (ORCPT ); Mon, 13 Jan 2014 12:03:30 -0500 Received: from mail-we0-f179.google.com ([74.125.82.179]:60703 "EHLO mail-we0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754833AbaAMRD0 (ORCPT ); Mon, 13 Jan 2014 12:03:26 -0500 MIME-Version: 1.0 In-Reply-To: <20140103151154.GA2940@cerebellum.variantweb.net> References: <1387459407-29342-1-git-send-email-ddstreet@ieee.org> <20140103151154.GA2940@cerebellum.variantweb.net> From: Dan Streetman Date: Mon, 13 Jan 2014 12:03:05 -0500 X-Google-Sender-Auth: ugTAVmBu-Gm_Amt7IpKFpdyqESw Message-ID: Subject: Re: [PATCH] mm/zswap: add writethrough option To: Andrew Morton , Seth Jennings Cc: Linux-MM , linux-kernel , Bob Liu , Minchan Kim , Weijie Yang , Shirish Pargaonkar , Mel Gorman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ping to see if this patch can get picked up. On Fri, Jan 3, 2014 at 10:11 AM, Seth Jennings wrote: > On Thu, Dec 19, 2013 at 08:23:27AM -0500, Dan Streetman wrote: >> Currently, zswap is writeback cache; stored pages are not sent >> to swap disk, and when zswap wants to evict old pages it must >> first write them back to swap cache/disk manually. This avoids >> swap out disk I/O up front, but only moves that disk I/O to >> the writeback case (for pages that are evicted), and adds the >> overhead of having to uncompress the evicted pages and the >> need for an additional free page (to store the uncompressed page). >> >> This optionally changes zswap to writethrough cache by enabling >> frontswap_writethrough() before registering, so that any >> successful page store will also be written to swap disk. The >> default remains writeback. To enable writethrough, the param >> zswap.writethrough=1 must be used at boot. >> >> Whether writeback or writethrough will provide better performance >> depends on many factors including disk I/O speed/throughput, >> CPU speed(s), system load, etc. In most cases it is likely >> that writeback has better performance than writethrough before >> zswap is full, but after zswap fills up writethrough has >> better performance than writeback. >> >> Signed-off-by: Dan Streetman > > Hey Dan, sorry for the delay on this. Vacation and busyness. > > This looks like a good option for those that don't mind having > the write overhead to ensure that things don't really bog down > if the compress pool overflows, while maintaining the read fault > speedup by decompressing from the pool. > > Acked-by: Seth Jennings -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/