On Tue, Nov 06, 2012 at 10:46:28AM +, Poul-Henning Kamp wrote:
>
> In message <5098e8b4.5040...@freebsd.org>, Andre Oppermann writes:
>
> >> I think it should go away, and if there still is a relevant
> >> usage segment, be replaced by _real_ "device-polling" which is
> >> not tied to
On Nov 6, 2012, at 4:31 AM, Chuck Burns wrote:
> On Tuesday, November 06, 2012 12:36:46 PM Andre Oppermann wrote:
>> On 06.11.2012 12:30, Luigi Rizzo wrote:
>>> On Tue, Nov 06, 2012 at 11:23:34AM +0100, Andre Oppermann
> wrote:
>>> ...
>>>
Hi Luigi,
do you agree on polling having
Le 6 nov. 2012 à 12:42, Andre Oppermann a écrit :
> On 06.11.2012 12:02, Fabien Thomas wrote:
>>>
>>> Hi Luigi,
>>>
>>> do you agree on polling having outlived its usefulness in the light
>>> of interrupt moderating NIC's and SMP complications/disadvantages?
>>>
>> If you have only one i
On Tuesday, November 06, 2012 12:36:46 PM Andre Oppermann wrote:
> On 06.11.2012 12:30, Luigi Rizzo wrote:
> > On Tue, Nov 06, 2012 at 11:23:34AM +0100, Andre Oppermann
wrote:
> > ...
> >
> >> Hi Luigi,
> >>
> >> do you agree on polling having outlived its usefulness in the light
> >> of interru
On 06.11.2012 12:02, Fabien Thomas wrote:
Hi Luigi,
do you agree on polling having outlived its usefulness in the light
of interrupt moderating NIC's and SMP complications/disadvantages?
If you have only one interface yes polling is not really necessary.
If you have 10 interfaces the inter
On 06.11.2012 12:30, Luigi Rizzo wrote:
On Tue, Nov 06, 2012 at 11:23:34AM +0100, Andre Oppermann wrote:
...
Hi Luigi,
do you agree on polling having outlived its usefulness in the light
of interrupt moderating NIC's and SMP complications/disadvantages?
yes, we should let it rest in peace.
On Tue, Nov 06, 2012 at 11:23:34AM +0100, Andre Oppermann wrote:
...
> Hi Luigi,
>
> do you agree on polling having outlived its usefulness in the light
> of interrupt moderating NIC's and SMP complications/disadvantages?
yes, we should let it rest in peace.
One part of the NIC-polling framework
>>
>
> Hi Luigi,
>
> do you agree on polling having outlived its usefulness in the light
> of interrupt moderating NIC's and SMP complications/disadvantages?
>
If you have only one interface yes polling is not really necessary.
If you have 10 interfaces the interrupt moderation threshold is ha
In message <5098e8b4.5040...@freebsd.org>, Andre Oppermann writes:
>> I think it should go away, and if there still is a relevant
>> usage segment, be replaced by _real_ "device-polling" which is
>> not tied to the network stack.
>
>Don't we already have the equivalent with a fast interru
On 06.11.2012 11:27, Poul-Henning Kamp wrote:
In message <5098e526.6070...@freebsd.org>, Andre Oppermann writes:
Hi Luigi,
do you agree on polling having outlived its usefulness in the light
of interrupt moderating NIC's and SMP complications/disadvantages?
Can I just point out, tha
In message <5098e526.6070...@freebsd.org>, Andre Oppermann writes:
>Hi Luigi,
>
>do you agree on polling having outlived its usefulness in the light
>of interrupt moderating NIC's and SMP complications/disadvantages?
Can I just point out, that what we have is not in fact "device-polling"
On 05.11.2012 17:57, Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
doh, running kernel wasn't as GENERIC as I thought it was, loo
Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device pollin
Joe Holden wrote:
> It looks like the device polling is what was causing it, once I'd
> removed that from kernconf it returned to normal - full interupt rate is
> ok though if I can increase the rate to a decent level
FWIW, this is how my igb(4) system is tuned and with PF, it's able
to fill 4xi
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device pollin
On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote:
> Luigi Rizzo wrote:
> >On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
> >>On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
> >>
> >>>doh, running kernel wasn't as GENERIC as I thought it was, looks like
> >>>device polling
Alexander Motin wrote:
Hi.
Full interrupt rate on some CPU means that your system is not idle, but
running some process. Another possibility is that you have DUMMYNET
compiled into your kernel, which tends to schedule callout for every HZ
tick, effectively blocking skipping interrupts for one
Luigi Rizzo wrote:
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
doh, running kernel wasn't as GENERIC as I thought it was, looks like
device polling not only breaks dynamic ticks but also reduces rx ability
significantly, exactl
On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote:
> On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
>
> > doh, running kernel wasn't as GENERIC as I thought it was, looks like
> > device polling not only breaks dynamic ticks but also reduces rx ability
> > significantly, exactly 150,0
Hi.
Full interrupt rate on some CPU means that your system is not idle, but
running some process. Another possibility is that you have DUMMYNET
compiled into your kernel, which tends to schedule callout for every HZ
tick, effectively blocking skipping interrupts for one of CPUs.
Check 'top -
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote:
> doh, running kernel wasn't as GENERIC as I thought it was, looks like
> device polling not only breaks dynamic ticks but also reduces rx ability
> significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without
>
> Is this a known is
Davide Italiano wrote:
On Nov 4, 2012 10:40 PM, "Joe Holden" wrote:
Davide Italiano wrote:
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden wrote:
Hi guys,
Has some default changed between 9.1-RC2 and HEAD?
On identical machines, one with 9.1-RC2 and one with HEAD from yesterday
(GENERIC) I see
On Nov 4, 2012 10:40 PM, "Joe Holden" wrote:
>
> Davide Italiano wrote:
>>
>> On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden wrote:
>>>
>>> Hi guys,
>>>
>>> Has some default changed between 9.1-RC2 and HEAD?
>>>
>>> On identical machines, one with 9.1-RC2 and one with HEAD from yesterday
>>> (GENERIC
Davide Italiano wrote:
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden wrote:
Hi guys,
Has some default changed between 9.1-RC2 and HEAD?
On identical machines, one with 9.1-RC2 and one with HEAD from yesterday
(GENERIC) I see the following in systat -v:
9.1:
65 cpu0:timer
10 cpu1:timer
HEAD:
11
On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden wrote:
> Hi guys,
>
> Has some default changed between 9.1-RC2 and HEAD?
>
> On identical machines, one with 9.1-RC2 and one with HEAD from yesterday
> (GENERIC) I see the following in systat -v:
>
> 9.1:
> 65 cpu0:timer
> 10 cpu1:timer
>
> HEAD:
> 1127 c
Hi guys,
Has some default changed between 9.1-RC2 and HEAD?
On identical machines, one with 9.1-RC2 and one with HEAD from yesterday
(GENERIC) I see the following in systat -v:
9.1:
65 cpu0:timer
10 cpu1:timer
HEAD:
1127 cpu0:timer
22 cpu1:timer
These are Supermicro i3 boxes and as far as
27 matches
Mail list logo
