From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qing He Subject: Re: [RFC] irq rate limit Date: Thu, 10 Sep 2009 17:05:26 +0800 Message-ID: <20090910090526.GC25462@ub-qhe2> References: <20090909090700.GB25462@ub-qhe2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Wed, 2009-09-09 at 17:29 +0800, Keir Fraser wrote: > On 09/09/2009 10:07, "Qing He" wrote: > > >> What's the generation counter for? Why not just zero desc->rl_cnt in the > >> timer handler? > > > > If zeroing desc->rl_cnt in the timer handler, we have to zero that of > > all irqs. If the numbers of possible irqs is big or sparse, it's a bit > > painful. > > Ah yes, I see. An always-on 10ms timer is ugly however. The Intel guys > working on power management won't like it as it will reduce deep-sleep > residency. Yes, I also knew it's not PM friendly, but didn't come up with a good solution. > > I would suggest getting rid of the generation counter and enable the timer > only when the irq_ratelimit_list is non-empty. In do_IRQ(), when rl_cnt > exceeds the threshold: > now = NOW(); > if ( now < (desc->rl_quantum_start + MILLISECS(10)) ) > Add to irq_ratelimit_list; Kick timer if list was previously empty; > else > desc->rl_cnt = 0; desc->rl_quantum_start = now; > > And in the timer handler, for each desc on the list: > desc->rl_cnt = 0; desc->rl_quantum_start = now; > > And at the end of the timer handler, do not set_timer(). > > This approach adds the overhead of get_s_time() every > irq_ratelimit_threshold interrupts, which should be unmeasurably tiny. This is OK to me, didn't think of this method. I'll rework the patch like this. Thanks, Qing > > -- Keir > >