Re: [PATCH V6 5/5] xen: Handle resumed instruction based on previous mem_event reply

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 09/11/2014 01:09 PM, George Dunlap wrote:
> So just to explain a bit where we're coming from: We're always happy
> to have improvements from people, and we're glad to have more people
> using Xen.  But there are interfaces that we're going to have to be
> supporting long-term.  When you're writing a product and you own the
> entire piece of code, you can make all these kinds of changes however
> you want; the only people it will affect in the future are you.
> Adding them to a shared project like Xen, they affect lots of other
> people who aren't doing what you're doing.   Furthermore, every
> addition to the interface makes it a tiny bit more complicated,
> fragile, and easy to break; and it's fairly likely that we'll end up
> being the ones having to fix it at some point.

Thank you for the message, it's appreciated! Fair enough.

> So with that in mind:
> 
> This "don't give a notification on npfec_kind_with_gla" is a separate
> feature that should have been introduced in a separate patch.  Of
> course it's nice not to have to do context switches when you don't
> have to; but adding a whole raft of flags for events you want to be
> able to skip opens up a can of worms interface wise.  So it needs to
> be justified. How expensive is it actually to just have the controller
> ignore these?  How many unwanted events like this do you get on a
> regular basis, and does it actually have a measurable performance
> impact?
> 
> And if it does have a measurable performance impact, is it likely that
> we're going to have other events that we may want to be able to filter
> out in the hypervisor?  Is it better to think about a more general /
> scalable way of specifying these events, rather than adding flags in
> an ad-hoc fashion as they come up?
> 
> On the whole, if you're hoping to have the less controversial bits
> (patches 1-3, and the other half of this patch) in 4.5, you might want
> to set this to the side and come back to it after the code freeze is
> done.

The impact is acceptable, I'll do the filtering in the application.
Thanks for the suggestion! I'll do a bit more testing, and if all goes
well I'll resubmit the series as patches 1-3, and 5 without the GLA
filtering.


Thanks,
Razvan Cojocaru