[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

>>> On 25.01.16 at 06:26, <feng.wu@xxxxxxxxx> wrote:

>> -----Original Message-----
>> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
>> Sent: Wednesday, January 20, 2016 9:31 PM
>> To: Jan Beulich <JBeulich@xxxxxxxx>; Wu, Feng <feng.wu@xxxxxxxxx>
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; George Dunlap
>> <george.dunlap@xxxxxxxxxxxxx>; Tian, Kevin <kevin.tian@xxxxxxxxx>; xen-
>> devel@xxxxxxxxxxxxx; Keir Fraser <keir@xxxxxxx>
>> Subject: Re: [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling
>> On Wed, 2016-01-20 at 04:35 -0700, Jan Beulich wrote:
>> > > > > On 20.01.16 at 12:20, <feng.wu@xxxxxxxxx> wrote:
>> > > >
>> > > > Then you didn't understand: The question isn't this path, but the
>> > > > path where the hook gets called if non-NULL (and hence the
>> > > > possibility to avoid such needless calls).
>> > >
>> > > I understand you mean the overhead happens when the hooks
>> > > is called. My point is the hook is not called in a critical path,
>> > > so I doubt
>> > > whether it worth doing so to make the logic complex.
>> >
>> > Are you sure scheduling code is not a critical path?
>> >
>> TBH, I like Jan's point... It's always good to make all we can to avoid
>> calling the hook, if unnecessary.
>> Does it really complicates things a lot? Feng, can you give it a try?
> After more thinking about this, it seems to me avoiding the checking
> of assigned devices and spinlocks in vmx_pi_switch_from() and
> vmx_pi_switch_to() is more meaningful, since this two functions are
> the real ones involved in scheduling than arch_vcpu_block(), should 
> we also use the method Jan mentioned above to avoid the overhead
> in these two function. To achieve this, we have some issues, since
> these two functions are not hooks (they are called in other hooks).
> vmx_pi_so_resume() has the same problem as well.
> Can we do it this way?
> - Define the three functions above as hooks in 'v->arch.hvm_vmx'.
> - Initial them when the first device is assigned and zap them when the
> last assigned device is de-assigned.
> Jan and Dario, any ideas?

To be honest, questions of this sort irritate me: I simply can't
tell how neat or ugly the result would be without seeing the
result. Use your judgment in such cases, and simply be
prepared to answer questions as to why a specific choice was
made, or how much worse alternatives would have been.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.