Re: [Xen-devel] heavy P2M lock contention on guest HPET counter reads

[Andres Lagar Cavilla <andres@xxxxxxxxxxxxxxxx>]

On Mon, Aug 4, 2014 at 3:00 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 02.08.14 at 04:33, <andres@xxxxxxxxxxxxxxxx> wrote:
> On Fri, Aug 1, 2014 at 2:38 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
>> >>> On 30.07.14 at 20:15, <andres@xxxxxxxxxxxxxxxx> wrote:
>> > Having said that, I don't know off the top of my head that is obviously
>> > correct to shortcut the p2m lookup for msix table and iommu. I think so,
>> > but...
>>
>> All internal MMIO ranges are what you'd call "positively decoded" on
>> real hardware, i.e. they ought to supersede any other address
>> decoding rules anyway. Since they're also not associated with
>> possibly varying MFNs, the P2M lookup on them is simply pointless,
>> and short-circuiting them is imo at once making better guarantees
>> towards consistent behavior.
>>
> Ok. Good. However: this is a very hot path. I wonder if this iteration can
> be made more efficient (i.e sort the resulting mmio regions and do binary
> search).

How much more efficient would a binary search be for currently five
handlers? Furthermore, ->check_handler() involves more than just
an address range comparison in at least some of the cases.

Not much more efficient, given the almost zero odds of having more than five mmio handlers that can skip p2m lookup.

The only better performant option seems open-coding. Given the sensitivity of the path, I'd say stick with the original plan with two open coded if's (blatant backtrack!)

Let me know if you'd rather we follow the route I laid out here.

Thanks
Andres

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel