From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH V6 5/5] xen: Handle resumed instruction based on previous mem_event reply Date: Thu, 11 Sep 2014 13:44:30 +0300 Message-ID: <54117D0E.4090404@bitdefender.com> References: <1410258512-2955-1-git-send-email-rcojocaru@bitdefender.com> <1410258512-2955-6-git-send-email-rcojocaru@bitdefender.com> <54107873.1040001@bitdefender.com> <5410C266.1060007@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XS1rk-0000nb-DA for xen-devel@lists.xenproject.org; Thu, 11 Sep 2014 10:44:40 +0000 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 40EDB80003 for ; Thu, 11 Sep 2014 13:44:37 +0300 (EEST) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "Tian, Kevin" , Keir Fraser , Ian Campbell , Stefano Stabellini , Jun Nakajima , "Dong, Eddie" , Ian Jackson , Tim Deegan , Andres Lagar Cavilla , Jan Beulich , Andrew Cooper , xen-devel List-Id: xen-devel@lists.xenproject.org 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