From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v2 09/13] xsplice: Implement support for applying/reverting/replacing patches. (v2) Date: Fri, 5 Feb 2016 14:30:56 -0500 Message-ID: <20160205193056.GD26294@x230.dumpdata.com> References: <1452808031-706-1-git-send-email-konrad.wilk@oracle.com> <1452808031-706-10-git-send-email-konrad.wilk@oracle.com> <569E4AAC.9070100@citrix.com> <20160119165543.GD17737@char.us.oracle.com> <56A60A4E.3070107@citrix.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 1aRm63-00088l-AS for xen-devel@lists.xenproject.org; Fri, 05 Feb 2016 19:31:11 +0000 Content-Disposition: inline In-Reply-To: <56A60A4E.3070107@citrix.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: Ross Lagerwall Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, mpohlack@amazon.com, stefano.stabellini@citrix.com, jbeulich@suse.com, sasha.levin@oracle.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org > >>As far as I can tell, the mechanics of how this works haven't changed, the > >>code has just been reorganized. Which means the points that Martin raised > >>about this mechanism are still outstanding. > > > >A bit. I added the extra timeout on both of the 'spin-around' and also > >moved some of the barriers around. Also removed your spin-lock and used > >the atomic_t mechanism to synchronize. > > > >But the one thing that I didn't do was the spin on the 'workers?' that > >are just spinnig idly. They will do that forever if say the 'master' > >hasn't gone to the IRQ semaphore part. > > > >My thinking was that the 'workers' could also use the timeout feature > >but just multiple it by two? > > > > After looking at this again, I remembered that the algorithm I used is the > same as the one used by stop_machine_run(). That function runs without > timeouts at all (seemingly without problems), so why shouldn't this one? Because we may have a very busy system and we do not want to impair the running guests. > (The only reason stop_machine_run() itself isn't used for patching is > because we need to enter the function without a stack, i.e. not from a > tasklet.) > > -- > Ross Lagerwall