From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751536Ab1KBUwk (ORCPT ); Wed, 2 Nov 2011 16:52:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31728 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750906Ab1KBUwi (ORCPT ); Wed, 2 Nov 2011 16:52:38 -0400 Message-ID: <4EB1AD53.2000600@redhat.com> Date: Wed, 02 Nov 2011 16:51:31 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dan Magenheimer CC: Andrea Arcangeli , Pekka Enberg , Cyclonus J , Sasha Levin , Christoph Hellwig , David Rientjes , Linus Torvalds , linux-mm@kvack.org, LKML , Andrew Morton , Konrad Wilk , Jeremy Fitzhardinge , Seth Jennings , ngupta@vflare.org, Chris Mason , JBeulich@novell.com, Dave Hansen , Jonathan Corbet Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window) References: <75efb251-7a5e-4aca-91e2-f85627090363@default> <20111027215243.GA31644@infradead.org> <1319785956.3235.7.camel@lappy> <552d2067-474d-4aef-a9a4-89e5fd8ef84f@default20111031181651.GF3466@redhat.com> <60592afd-97aa-4eaf-b86b-f6695d31c7f1@default 20111031223717.GI3466@redhat.com> <1b2e4f74-7058-4712-85a7-84198723e3ee@default> In-Reply-To: <1b2e4f74-7058-4712-85a7-84198723e3ee@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/31/2011 07:36 PM, Dan Magenheimer wrote: >> From: Andrea Arcangeli [mailto:aarcange@redhat.com] >>> real work to do instead and (2) that vmexit/vmenter is horribly >> >> Sure the CPU has another 1000 VM to schedule. This is like saying >> virtio-blk isn't needed on desktop virt becauase the desktop isn't >> doing much I/O. Absurd argument, there are another 1000 desktops doing >> I/O at the same time of course. > > But this is truly different, I think at least for the most common > cases, because the guest is essentially out of physical memory if it > is swapping. And the vmexit/vmenter (I assume, I don't really > know KVM) gives the KVM scheduler the opportunity to schedule > another of those 1000 VMs if it wishes. I believe the problem Andrea is trying to point out here is that the proposed API cannot handle a batch of pages to be pushed into frontswap/cleancache at one time. Even if the current back-end implementations are synchronous and can only do one page at a time, I believe it would still be a good idea to have the API able to handle a vector with a bunch of pages all at once. That way we can optimize the back-ends as required, at some later point in time. If enough people start using tmem, such bottlenecks will show up at some point :)