From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts Date: Wed, 26 Jan 2011 14:08:51 +0200 Message-ID: <20110126120851.GA11913@redhat.com> References: <1295966492.3230.55.camel@x201> <4D3EE3F8.3020603@redhat.com> <20110125145955.GE15666@redhat.com> <4D3F0974.3040904@redhat.com> <20110125175839.GC17734@redhat.com> <4D3FE697.4010502@redhat.com> <20110126092038.GD2704@redhat.com> <4D3FE809.6020102@redhat.com> <20110126093933.GF2704@redhat.com> <4D3FEF4D.9080008@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Williamson , Jan Kiszka , Marcelo Tosatti , "kvm@vger.kernel.org" , "ddutile@redhat.com" , "chrisw@redhat.com" To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53982 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753163Ab1AZMJK (ORCPT ); Wed, 26 Jan 2011 07:09:10 -0500 Content-Disposition: inline In-Reply-To: <4D3FEF4D.9080008@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 26, 2011 at 11:54:21AM +0200, Avi Kivity wrote: > On 01/26/2011 11:39 AM, Michael S. Tsirkin wrote: > >On Wed, Jan 26, 2011 at 11:23:21AM +0200, Avi Kivity wrote: > >> On 01/26/2011 11:20 AM, Michael S. Tsirkin wrote: > >> >On Wed, Jan 26, 2011 at 11:17:11AM +0200, Avi Kivity wrote: > >> >> On 01/25/2011 07:58 PM, Michael S. Tsirkin wrote: > >> >> >On Tue, Jan 25, 2011 at 07:33:40PM +0200, Avi Kivity wrote: > >> >> >> On 01/25/2011 04:59 PM, Michael S. Tsirkin wrote: > >> >> >> >On Tue, Jan 25, 2011 at 04:53:44PM +0200, Avi Kivity wrote: > >> >> >> >> For the other lookups, which we > >> >> >> >> believe will succeed, we can assume the probablity of a match is > >> >> >> >> related to the slot size, and sort the slots by page count. > >> >> >> > > >> >> >> >Unlikely to be true for assigned device BARs. > >> >> >> > >> >> >> We'll have a large slot at 4G+ - EOM, a medium slot at 1M-3G, and > >> >> >> lots of small slots for BARs and such. > >> >> >> > >> >> >> The vast majority of faults will either touch one of the two largest > >> >> >> slots, or will miss all slots. Relatively few will hit the small > >> >> >> slots. > >> >> > > >> >> >Not if you are using one of the assigned devices and don't > >> >> >do any faults on memory :) > >> >> > >> >> It's impossible not to fault on memory. > >> > > >> >No I mean the RAM. > >> > >> No idea what you mean. It's impossible not to fault on RAM, either > >> (unless you don't use it at all). > > > >I just mean that once you fault you map sptes and then you can use them > >without exits. mmio will cause exits each time. Right? > > The swapper scanning sptes, ksmd, khugepaged, and swapping can all > cause a page to be unmapped. Though it should certainly happen with > a much lower frequency than mmio. Right. That's why I say that sorting by size might not be optimal. Maybe a cache ... > -- > error compiling committee.c: too many arguments to function