Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Aug 2013 13:05:51 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-current@freebsd.org
Cc:        Venkata Duvvuru <VenkatKumar.Duvvuru@emulex.com>
Subject:   Re: OCE driver on Freebsd 10.0-Current
Message-ID:  <201308231305.51726.jhb@freebsd.org>
In-Reply-To: <BF3270C86E8B1349A26C34E4EC1C44CB2BD65B1B@CMEXMB1.ad.emulex.com>
References:  <BF3270C86E8B1349A26C34E4EC1C44CB2BD65B1B@CMEXMB1.ad.emulex.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 23, 2013 4:55:06 am Venkata Duvvuru wrote:
> Hi,
> 
> I'm running iperf on Emulex's OCE network adapter in Freebsd-10-current. At
> heavy traffic (iperf with ~10 connections), iperf is hanging. The same
> driver is working on all other Freebsd versions.
> 
> top -HS shows the below information.
> 
> PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
> 
>    11 root       155 ki31     0K   128K CPU4    4 146:36 100.00% idle{idle: cpu4}
> 
>    12 root       -60    -     0K   688K CPU6    6  52:38 100.00% intr{swi4: clock}
> 
>    11 root       155 ki31     0K   128K CPU2    2 148:42 99.66% idle{idle: cpu2}
> 
>    11 root       155 ki31     0K   128K CPU7    7 149:24 99.27% idle{idle: cpu7}
> 
>    11 root       155 ki31     0K   128K RUN     0 148:00 99.27% idle{idle: cpu0}
> 
>    11 root       155 ki31     0K   128K CPU1    1 149:44 99.17% idle{idle: cpu1}
> 
>    11 root       155 ki31     0K   128K CPU5    5 148:46 99.17% idle{idle: cpu5}
> 
>    11 root       155 ki31     0K   128K CPU3    3  96:57 89.06% idle{idle: cpu3}
> 
>    11 root       155 ki31     0K   128K RUN     6 149:11 13.87% idle{idle: cpu6}
> 
> 
> 
> One interesting thing I observed is that intr is taking 100% on CPU6 when
> iperf hangs, while iperf is running fine, the intr WCPU percentage is very
> low. What does this below line mean? Why intr is 100% on CPU6??
> 
> 12 root       -60    -     0K   688K CPU6    6  52:38 100.00% intr{swi4: clock}

This is the thread that runs timers configured via callout_reset() or
timeout().  Those are handled differently in 10 than in older branches.
I suspect you have a callout that is rescheduling itself constantly or
some such.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201308231305.51726.jhb>