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.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
