On 2012-04-04 10:53, Michael S. Tsirkin wrote:
> On Wed, Apr 04, 2012 at 11:44:23AM +0300, Avi Kivity wrote:
>> On 04/04/2012 11:38 AM, Michael S. Tsirkin wrote:
>>>>
>>>>>
>>>>> A performance note: delivering an interrupt needs to search all vcpus
>>>>> for an APIC ID match. The previous plan was to cache (or pre-calculate)
>>>>> this lookup in the irq routing table. Now it looks like we'll need a
>>>>> separate cache for this.
>>>>
>>>> As this is non-existent until today, we don't regress here. And it can
>>>> still be added on top later on, transparently.
>>>
>>> I always worry about hash collisions and the cost of
>>> calculating good hash functions.
>>>
>>> We could instead return an index in the cache on injection, maintain in
>>> userspace and use it for fast path on the next injection.
>>
>> Ahem, that is almost the existing routing table to a T.
>>
>>> Will make it easy to use an array index instead of a hash here,
>>> and fallback to a slower ID lookup on mismatch.
>>
>> Need a free ioctl so we can reuse IDs.
>
> No, it could be kernel controlled not userspace controlled. We get both
> and address and an index:
>
> if (table[u.i].addr == u.addr && table[u.i].data == u.data) {
> return table[u.i].id;
> }
>
> u.i = find_lru_idx(&table);
> table[u.i].addr = u.addr;
> table[u.i].data = u.data;
> table[u.i].id = find_id(u.addr, u.data);
> return table[u.i].id;
>
>
>>> Until we do have this fast path we can just fill this value with zeros,
>>> so kernel patch (almost) does not need to change for this -
>>> just the header.
>>
>> Partially implemented interfaces invite breakage.
>
> Hmm true. OK scrap this idea then, it's not clear
> whether we are going to optimize this anyway.
>
Also, the problem is that keeping that ID in userspace requires an
infrastructure like the MSIRoutingCache that I proposed originally. Not
much won /wrt invasiveness there. So we should really do the routing
optimization in the kernel - one day.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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
