From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 0/2] make hypercall preemption checks consistent Date: Tue, 4 Mar 2014 14:07:50 +0000 Message-ID: <5315DE36.5070705@citrix.com> References: <5315C5370200007800120CE4@nat28.tlf.novell.com> <5315BE66.5030903@citrix.com> <5315CE6F0200007800120D68@nat28.tlf.novell.com> <5315C2D0.1030500@citrix.com> <5315DDDD0200007800120DDF@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WKq0h-00018V-Kx for xen-devel@lists.xenproject.org; Tue, 04 Mar 2014 14:07:55 +0000 In-Reply-To: <5315DDDD0200007800120DDF@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , Keir Fraser , xen-devel List-Id: xen-devel@lists.xenproject.org On 04/03/14 13:06, Jan Beulich wrote: >>>> On 04.03.14 at 13:10, David Vrabel wrote: >> On 04/03/14 12:00, Jan Beulich wrote: >>>>>> On 04.03.14 at 12:52, Andrew Cooper wrote: >>>> On 04/03/14 11:21, Jan Beulich wrote: >>>>> - never preempt on the first iteration (ensure forward progress) >>>>> - never preempt on the last iteration (pointless/wasteful) >>>>> - do cheap checks first >>>>> >>>>> 1: common: make hypercall preemption checks consistent >>>>> 2: x86: make hypercall preemption checks consistent >>>>> >>>>> Signed-off-by: Jan Beulich >>>> >>>> All in all, this is a good improvement over what is currently present. >>>> >>>> However, given the overhead of creating continuations (particularly for >>>> 32bit HVM guests, which have been seen to unconditionally fail the >>>> preemption check by the time the compat layer has run), some of these >>>> operations would probably be better having more than a single guaranteed >>>> operation. >>> >>> I agree, but I wanted to do one step at a time. Judging how much >>> work we want to permit done between preemption points will be >>> either heavy guess work, or require quite a bit of performance >>> measurement... >> >> Perhaps something time-based? Record the time at start and make >> hypercall_preempt_check() return true if more than T time has elapsed? > > That's certainly an interesting idea. But it doesn't remove the need > to determine the actual value of the parameter to use (T in this case). Sure, but it should be just one parameter for all hypercalls instead of having to consider each one separately. David