Re: [PATCH] Refactor ioreq server for better performance

["Yu, Zhang" <yu.c.zhang@linux.intel.com>]

[snip]

>>
>> Thanks, Paul.
>> Well, I agree the former approach would be simpler. But I still doubt
>> if this is more reasonable. :)
>> IIUC, one of the reasons for struct domain to have a rangeset list(and
>> a spinlock - rangesets_lock), is because there are iomem_caps and
>> irq_caps for each domain. These 2 rangeset members of struct domain are
>> platform independent.
>> However, struct rb_rangeset is only supposed to be used in ioreq
>> server, which is only for x86 hvm cases. Adding a rb_rangeset list
>> member(similarly, if so, a rb_rangesets_lock is also required) in
>> struct domain maybe useless for hardware domain and for platforms other
>> than x86.
>
> Fair enough.
>
>> So, I'd like to register a new debug key, to dump the ioreq server
>> informations, just like the keys to dump iommu p2m table or the irq
>> mappings. With a new debug key, we do not need to add a spinlock for
>> rb_rangeset in struct domain, the one in ioreq server would be enough.
>> Does this sound reasonable?
>>
>
> That would be ok with me, but I'm not sure about claiming a whole debug key for this. Is there any other one that you could piggy-back on? If not, then maybe just make it part of the 'q' output.

Thanks, my new implementation uses the 'q' debug key. Will send out the
new version later. :)

Yu
>
>    Paul
>

[snip]

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