From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH V4] Switch from select() to poll() in xenconsoled's IO loop Date: Mon, 7 Jan 2013 15:24:39 +0000 Message-ID: <1357572279.13581.13.camel@iceland> References: <1357233257-13918-1-git-send-email-wei.liu2@citrix.com> <1357568895.11865.1.camel@iceland> <50EADE9B.5090109@citrix.com> <1357570908.13581.9.camel@iceland> <1357571769.7989.114.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1357571769.7989.114.camel@zakaz.uk.xensource.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: Ian Campbell Cc: Mats Petersson , wei.liu2@citrix.com, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Mon, 2013-01-07 at 15:16 +0000, Ian Campbell wrote: > On Mon, 2013-01-07 at 15:01 +0000, Wei Liu wrote: > > On Mon, 2013-01-07 at 14:41 +0000, Mats Petersson wrote: > > > > > > return; > > > > @@ -982,11 +1024,7 @@ void handle_io(void) > > > > /* Re-calculate any event counter allowances & unblock > > > > domains with new allowance */ > > > > for (d = dom_head; d; d = d->next) { > > > > - /* Add 5ms of fuzz since select() often returns > > > > - a couple of ms sooner than requested. Without > > > > - the fuzz we typically do an extra spin in select() > > > > - with a 1/2 ms timeout every other iteration */ > > > > - if ((now+5) > d->next_period) { > > > > + if (now > d->next_period) { > > > Is poll more accurate than select? I would have thought that they were > > > based on the same timing, and thus equally "fuzzy"? > > > > Is there any actual proof that the fuzz is needed? Specs of both > > select() and poll() don't seem to mention this behaviour at all. > > I agree that it seems pretty dubious but it might be interesting to see > what strace shows, specifically if it shows this extra spin every other > iteration. > > The fuzz was introduced in 16257:955ee4fa1345 "Rate-limit activity > caused by each domU." but the commit log doesn't make any reference to > the reason for it. > > It may just have been a kernel bug at around the time that patch was > authored, but google doesn't seem to show any evidence of such a bug > ever being widespread (i.e. I don't find any references to it). > Then I will leave the fuzz here, and do another patch to remove it. I will also add reference to CS 16257 in the comment. Wei.