From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH for-4.5 v11 0/9] Mem_event and mem_access for ARM Date: Mon, 29 Sep 2014 16:07:10 +0100 Message-ID: <1412003230.3801.26.camel@citrix.com> References: <1411990609-22374-1-git-send-email-tklengyel@sec.in.tum.de> <1411997842.3801.16.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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: Tamas K Lengyel Cc: wei.liu2@citrix.com, Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On Mon, 2014-09-29 at 16:21 +0200, Tamas K Lengyel wrote: > The patch you reference in the previous round was newly added has been > refactored in this round to avoid adding overhead. If it's your > feeling that there might be some other similar cases and you want to > delay so you have more time to look at it just be sure, that's > perfectly understandable, but IMHO in this version there is no > indication that we are adding any unreasonable overhead. As I say I think we need to step back and take our time over this. I think 4.6 is the right target for this stuff, otherwise we are rushing and risking slipping in something which has an unexpected impact. > I don't see how those benchmarks would be meaningful for this series. > During normal operations, the only overhead for the domain would be in > the trap handlers checking the boolean flag if mem_access is in use in > case a permission fault happened in the second stage translation.. > which I have never observed happening during my tests. So those > benchmarks don't really exercise any paths that mem_access touches. It touches the p2m update code which is a hot path. Also it previously touched the copy to/from guest paths which is super hot, if you aren't doing that anymore then great, if you are then there is still a potential for regressions. But in any case the benchmarks will serve to highlight *unexpected* regressions to serve as confirmation of what you expect. For example I think they would would have pretty clearly shown poor performance due to the copy to/from user changes in your previous iteration. Ian.