RE: sysctl add macros
I could use an int variable but if I have to dump huge number of statistics through sysctl in which case I need to add many such variables to the nodes and even if most of these variables are char I have to declare them as int, hence resulting in an increased footprint. /Venkat. -Original Message- From: John-Mark Gurney [mailto:j...@funkthat.com] Sent: Sunday, December 01, 2013 3:00 AM To: Venkata Duvvuru Cc: Matthew Fleming; freebsd-current@freebsd.org Subject: Re: sysctl add macros Venkata Duvvuru wrote this message on Mon, Nov 25, 2013 at 14:58 +: The problem with using int or u_int for 1 or 2 byte values is that while printing these 1 or 2 byte values I observed that sysctl module is considering 4 bytes. Hence I see an undesired output. It is actually considering the next two bytes also as the value. If you _NEED_ to use a char or short, you need to write your own/clone it from the macros... Why can't you use an int for this variable? From: mdf...@gmail.com [mailto:mdf...@gmail.com] On Behalf Of Matthew Fleming Sent: Monday, November 25, 2013 8:18 PM To: Venkata Duvvuru Cc: freebsd-current@freebsd.org Subject: Re: sysctl add macros On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru venkatkumar.duvv...@emulex.commailto:venkatkumar.duvv...@emulex.com wrote: Hi, I'm unable to figure out how to add an unsigned short or an unsigned char values to a sysctl node. SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a short values I couldn't find any macros. Could you please let me know how to add them? FreeBSD does not have any sysctl handlers for 1 or 2 byte values. FreeBSD code that wants to do this has used int or u_int instead of a smaller type. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
sysctl add macros
Hi, I'm unable to figure out how to add an unsigned short or an unsigned char values to a sysctl node. SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a short values I couldn't find any macros. Could you please let me know how to add them? /Venkat. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: sysctl add macros
The problem with using int or u_int for 1 or 2 byte values is that while printing these 1 or 2 byte values I observed that sysctl module is considering 4 bytes. Hence I see an undesired output. It is actually considering the next two bytes also as the value. /Venkat. From: mdf...@gmail.com [mailto:mdf...@gmail.com] On Behalf Of Matthew Fleming Sent: Monday, November 25, 2013 8:18 PM To: Venkata Duvvuru Cc: freebsd-current@freebsd.org Subject: Re: sysctl add macros On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru venkatkumar.duvv...@emulex.commailto:venkatkumar.duvv...@emulex.com wrote: Hi, I'm unable to figure out how to add an unsigned short or an unsigned char values to a sysctl node. SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a short values I couldn't find any macros. Could you please let me know how to add them? FreeBSD does not have any sysctl handlers for 1 or 2 byte values. FreeBSD code that wants to do this has used int or u_int instead of a smaller type. Cheers, matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Freebsd-10.0-CURRENT problem in the bottom half
Hi,
In Freebsd 10.0-current with Emulex's OCE driver, I observe that the bottom
half is hogging all the CPU which is leading to system sluggishness. I used the
same hardware to check the behavior on 9.1-RELEASE, everything is fine, bottom
half is not taking more than 10% of the CPU even at the line rate speed. But
with half the throughput of line rate in Freebsd-10.0-current all the CPUs peak
and top -aSCHIP shows that it's all bottom half who is eating the CPU. I also
tried with Intel's 10g NIC to see if it has got the same problem and
interestingly it is also having the same problem, where bottom half is hogging
all the CPU.
We did some profiling to check where the problem is. I'm pasting the profiling
results for reference here. Observation from the results is that
uma_zalloc_arg== __mtx_lock_sleep is taking quite a bit of the CPU. We sleep
at a few places in the bottom half and I think the bottom half scheduling is
what is causing the problem. Please let me know if you see something very
obvious from the profiling data.
I'm seeing similar problem with ixgbe driver as well uma_zalloc_arg==
__mtx_lock_sleep is taking quite a bit of the CPU.
Top command results are also pasted below for both 10.0-current (where the
problem is seen) and 9.1-RELEASE (where the problem is not seen).
42.99% [372357] __mtx_lock_sleep @ /boot/kernel/kernel
100.0% [372357]__mtx_lock_flags
80.37% [299245] sosend_generic
100.0% [299245] soo_write
17.27% [64322] uma_zalloc_arg
50.43% [32438] m_copym
45.85% [29490] m_getm2
03.72% [2393]tcp_output
00.00% [1] oce_alloc_rx_bufs @ /boot/kernel/oce.ko
02.35% [8762] _sleep @ /boot/kernel/kernel
100.0% [8762]sbwait
00.00% [11] in_matroute
100.0% [11] rtalloc1_fib
00.00% [10] uma_zfree_arg
60.00% [6] m_freem
40.00% [4] sbdrop_internal
00.00% [3] rtalloc1_fib
100.0% [3] rtalloc_ign_fib
00.00% [3] tcp_output
100.0% [3] tcp_usr_send
00.00% [1] _cv_wait
100.0% [1] usb_process
34.98% [303027] trash_ctor @ /boot/kernel/kernel
87.44% [264956]mb_ctor_clust
100.0% [264956] uma_zalloc_arg
100.0% [264956] m_getm2
12.51% [37921] mb_ctor_mbuf
100.0% [37921] uma_zalloc_arg
48.28% [18308] m_getm2
48.18% [18272] m_copym
03.54% [1341]tcp_output
00.05% [150] mb_ctor_pack
100.0% [150]uma_zalloc_arg
96.67% [145] m_getm2
03.33% [5] oce_alloc_rx_bufs @ /boot/kernel/oce.ko
04.36% [37786]__rw_wlock_hard @ /boot/kernel/kernel
100.0% [37786] _rw_wlock_cookie
99.88% [37741] tcp_usr_send
100.0% [37741] sosend_generic
00.11% [43] in_pcblookup_hash
100.0% [43] tcp_input
Top -aSCHIP with Freebsd-10.0-CURRENT (throughput 4.5 Gbps)
PID USERNAME PRI NICE SIZERES STATE C TIMECPU COMMAND
0 root -920 0K 960K - 11 4:20 100.00% [kernel{oce1
taskq}]
2325 root 1030 70524K 6240K CPU55 0:39 100.00% iperf -c
12.0.238.24 -t 180 -i 3 -P 10{iperf}
0 root -920 0K 960K CPU88 5:17 99.37% [kernel{oce1
taskq}]
0 root -920 0K 960K CPU10 10 4:27 99.37% [kernel{oce1
taskq}]
0 root -920 0K 960K CPU99 3:35 98.88% [kernel{oce1
taskq}]
0 root -920 0K 960K CPU77 7:25 98.29% [kernel{oce1
taskq}]
11 root 155 ki31 0K 256K RUN12 14:55 93.90% [idle{idle:
cpu12}]
11 root 155 ki31 0K 256K CPU13 13 14:48 91.70% [idle{idle:
cpu13}]
11 root 155 ki31 0K 256K CPU14 14 18:35 89.79% [idle{idle:
cpu14}]
11 root 155 ki31 0K 256K RUN15 20:55 87.99% [idle{idle:
cpu15}]
11 root 155 ki31 0K 256K RUN 4 19:35 73.68% [idle{idle:
cpu4}]
11 root 155 ki31 0K 256K RUN 0 19:47 66.89% [idle{idle:
cpu0}]
11 root 155 ki31 0K 256K CPU22 18:53 64.89% [idle{idle:
cpu2}]
11 root 155 ki31 0K 256K CPU66 19:55 61.18% [idle{idle:
cpu6}]
11 root 155 ki31 0K 256K CPU11 18:46 55.66% [idle{idle:
cpu1}]
11 root 155 ki31 0K 256K RUN 5 19:41 42.48% [idle{idle:
cpu5}]
2325 root520 70524K 6240K sbwait 6 0:15 38.77% iperf -c
12.0.238.24 -t 180 -i 3 -P 10{iperf}
11 root 155 ki31 0K 256K CPU33 19:06 36.38% [idle{idle:
cpu3}]
2325 root490 70524K 6240K CPU11 0:14 35.06% iperf -c
12.0.238.24 -t 180 -i 3 -P 10{iperf}
2325 root440 70524K 6240K sbwait 0 0:13 33.59% iperf -c
12.0.238.24 -t 180 -i 3 -P 10{iperf}
2325 root420 70524K 6240K sbwait 2 0:13 33.15% iperf -c
12.0.238.24 -t 180 -i 3 -P 10{iperf}
2325 root410
taskqueue_enqueue_fast in freebsd 10.0-current
Hi, In Freebsd 10.0-current with Emulex's OCE driver, I observe that the bottom half is hogging all the CPU which is leading to system sluggishness. I used the same hardware to check the behavior on 9.1-RELEASE, everything is fine, bottom half is not taking more than 10% of the CPU even at the line rate speed. But with half the throughput of line rate in Freebsd-10.0-current all the CPUs peak and top -aSCHIP shows that it's all bottom half who is eating the CPU. Did anything changed in Freebsd-10.0-current that I should be careful about? Please clarify. Thanks, Venkat. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
OCE driver on Freebsd 10.0-Current
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 SIZERES STATE C TIME WCPU COMMAND
11 root 155 ki31 0K 128K CPU44 146:36 100.00% idle{idle:
cpu4}
12 root -60- 0K 688K CPU66 52:38 100.00% intr{swi4:
clock}
11 root 155 ki31 0K 128K CPU22 148:42 99.66% idle{idle: cpu2}
11 root 155 ki31 0K 128K CPU77 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 CPU11 149:44 99.17% idle{idle: cpu1}
11 root 155 ki31 0K 128K CPU55 148:46 99.17% idle{idle: cpu5}
11 root 155 ki31 0K 128K CPU33 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 CPU66 52:38 100.00% intr{swi4: clock}
/Venkat.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
