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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html