[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |