Subject: Re: [PATCH v6] net: batch skb dequeueing from softnet input_pkt_queue

From: Arjan van de Ven <[email-masked]>
Date: Mon, 3 May 2010 18:11:45 -0700

On Mon, 3 May 2010 17:52:04 +0200
Andi Kleen <[email-masked]> wrote:
> > HPETs have more than one channel (2 or 3 historically, newer
> > chipsets iirc have a few more), so in principle we can split this
> > lock at least a little bit... if we can get to one hpet channel per
> > level 3 cache domain we'd already make huge progress in terms of
> > cost of the contention....
> 
> I suggested the same thing a few emails up @) (great minds think 
> alike etc.etc. @) . 
> 
> I'm not sure how difficult it would be to implement though.

the hardest part will be cases where the SMM code borrows higher HPET
channels or something.. not sure if they do, but.. color me a bit afraid
we'll find cases.

> 
> Potential issues:
> 
> Some user applications use the hpet channels directly through
> the character device interface so there would be a potential
> compatibility issue (but maybe that should be just moved
> to be emulated with a hrtimer ?)

we can and should just emulate this. Same for the rtc device I suspect.

> And if multiple broadcast controllers are elected this might
> make it harder to become idle.

not quite, as long as you do a directed broadcast. As long as there's a
predictable mapping for which cores group to which hpet channel.. won't
be that bad since you only need to wake up your own local subset.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org