From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id 2F9826004C0 for ; Sun, 2 May 2010 03:11:08 -0400 (EDT) Date: Sun, 2 May 2010 09:11:00 +0200 From: Pavel Machek Subject: Re: Frontswap [PATCH 0/4] (was Transcendent Memory): overview Message-ID: <20100502071059.GF1790@ucw.cz> References: <4BD3377E.6010303@redhat.com> <1c02a94a-a6aa-4cbb-a2e6-9d4647760e91@default4BD43033.7090706@redhat.com> <20100428055538.GA1730@ucw.cz> <1272591924.23895.807.camel@nimitz> <4BDA8324.7090409@redhat.com> <084f72bf-21fd-4721-8844-9d10cccef316@default> <4BDB026E.1030605@redhat.com> <4BDB18CE.2090608@goop.org4BDB2069.4000507@redhat.com> <3a62a058-7976-48d7-acd2-8c6a8312f10f@default> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a62a058-7976-48d7-acd2-8c6a8312f10f@default> Sender: owner-linux-mm@kvack.org To: Dan Magenheimer Cc: Avi Kivity , Jeremy Fitzhardinge , Dave Hansen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, hugh.dickins@tiscali.co.uk, ngupta@vflare.org, JBeulich@novell.com, chris.mason@oracle.com, kurt.hackel@oracle.com, dave.mccracken@oracle.com, npiggin@suse.de, akpm@linux-foundation.org, riel@redhat.com List-ID: > So there are two users of frontswap for which the synchronous > interface makes sense. I believe there may be more in the > future and you disagree but, as Jeremy said, "a general Linux > principle is not to overdesign interfaces for hypothetical users, > only for real needs." We have demonstrated there is a need > with at least two users so the debate is only whether the > number of users is two or more than two. > > Frontswap is a very non-invasive patch and is very cleanly > layered so that if it is not in the presence of either of > the intended "users", it can be turned off in many different > ways with zero overhead (CONFIG'ed off) or extremely small overhead > (frontswap_ops is never set; or frontswap_ops is set but the > underlying hypervisor doesn't support it so frontswap_poolid > never gets set). Yet there are less invasive solutions available, like 'add trim operation to swap_ops'. So what needs to be said here is 'frontswap is XX times faster than swap_ops based solution on workload YY'. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org