On Wed, Jan 26, 2011 at 11:54:21AM +0200, Avi Kivity wrote:

On 01/26/2011 11:39 AM, Michael S. Tsirkin wrote:

quoted

On Wed, Jan 26, 2011 at 11:23:21AM +0200, Avi Kivity wrote:

quoted

 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