[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] irq rate limit



On Wed, 2009-09-09 at 17:29 +0800, Keir Fraser wrote:
> On 09/09/2009 10:07, "Qing He" <qing.he@xxxxxxxxx> 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
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.