[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100503181145.4e39c2dd@infradead.org>
Date: Mon, 3 May 2010 18:11:45 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Andi Kleen <andi@...stfloor.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>, hadi@...erus.ca,
xiaosuo@...il.com, therbert@...gle.com, shemminger@...tta.com,
netdev@...r.kernel.org, lenb@...nel.org
Subject: Re: [PATCH v6] net: batch skb dequeueing from softnet
input_pkt_queue
On Mon, 3 May 2010 17:52:04 +0200
Andi Kleen <andi@...stfloor.org> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists