fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
8 years, 9 months
[patch f17 00/11] team: refresh to latest net-next
by Jiri Pirko
Refresh team driver co so it can work correctly with recent libteam version.
All patches are in net-next tree
David S. Miller (1):
team: Stop using NLA_PUT*().
Jiri Pirko (10):
team: add binary option type
team: add loadbalance mode
team: add support for per-port options
team: add bool option type
team: add user_linkup and user_linkup_enabled per-port option
team: ab: walk through port list non-rcu
team: add missed "statics"
team: lb: let userspace care about port macs
team: allow to enable/disable ports
team: add per-port option for enabling/disabling ports
drivers/net/team/Kconfig | 11 +
drivers/net/team/Makefile | 1 +
drivers/net/team/team.c | 523 +++++++++++++++++++++++------
drivers/net/team/team_mode_activebackup.c | 20 +-
drivers/net/team/team_mode_loadbalance.c | 174 ++++++++++
drivers/net/team/team_mode_roundrobin.c | 2 +-
6 files changed, 621 insertions(+), 110 deletions(-)
create mode 100644 drivers/net/team/team_mode_loadbalance.c
--
1.7.6.5
11 years, 9 months
[PATCH 00/11] Wacom Intuos4 Wireless support
by Peter Hutterer
A set of patches cherry-picked from upstream to make the Intuos4 Bluetooth
variant useful. Without these patches, some data is missing, so we miss out
on relative mode, pad buttons, wheel support, etc.
Cheers,
Peter
11 years, 9 months
Fedora Kernel Meeting Minutes 05-24-2012
by Josh Boyer
==============================
#fedora-meeting: Fedora Kernel
==============================
Meeting started by jwb at 18:00:29 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-05-25/fedora-kernel....
.
Meeting summary
---------------
* Release overview (jwb, 18:01:02)
* Release overview - F15 (jwb, 18:01:53)
* F15 to stay on 3.3.y until EOL (jwb, 18:05:24)
* bugs will be looked over and triaged one final time (jwb, 18:05:45)
* Release overview - F16 (jwb, 18:05:50)
* Release overview - F16/F17 (jwb, 18:07:33)
* F16/F17 moving to 3.4 once 3.3.7 moves to stable updates (jwb,
18:07:52)
* iwlwifi seems to have more issues. again. for like the 3rd kernel
release (jwb, 18:09:23)
* ACTION: jforbes to discuss 3.4 iwlwifi issues with linville before
rebase (jwb, 18:10:45)
* F17 Gold. Yay. 0-day kernel updates will be pending for all (jwb,
18:15:34)
* 3.4 rebase (iwlwifi issues aside) should close a number of f17 bugs
(jwb, 18:17:08)
* Release overview - rawhide (jwb, 18:17:41)
* rawhide rebased to 3.5 merge window (jwb, 18:20:21)
* uprobes merged and enabled (jwb, 18:20:26)
* Open Floor (jwb, 18:22:13)
* kernel-test regression test framework on fedorahosted now (jwb,
18:23:05)
* LINK: http://git.fedorahosted.org/git/?p=kernel-tests.git (jwb,
18:23:15)
Meeting ended at 18:30:11 UTC.
Action Items
------------
* jforbes to discuss 3.4 iwlwifi issues with linville before rebase
Action Items, by person
-----------------------
* jforbes
* jforbes to discuss 3.4 iwlwifi issues with linville before rebase
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jwb (54)
* davej (26)
* jforbes (18)
* nirik (8)
* zodbot (3)
* brunowolff (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
11 years, 10 months
CONFIG_NR_CPUS
by Xose Vazquez Perez
> * Tue Jan 17 2012 Dave Jones <davej(a)redhat.com>
> - Rawhide builds now use MAXSMP on x86.
> - For release builds, set x86-64 to support 64 CPUs.
> If larger systems become widespread, we can increase in an update.
_today_
amd: 4sockets * 16cores = 64
intel: 4sockets * 10cores * 2threads = 80
11 years, 10 months
3.5 merge started
by Josh Boyer
Mostly as FYI, I've started building the 3.5 merge window kernels today.
The one building in Koji right now boots on my local x86_64 system
without issue. I'm not sure if that trend will continue, but I plan on
testing locally before I do koji builds.
I've done the first round of Kconfig options settings. Secondary
architectures, please review this and let me know if you want/need
something set differently from how I have it.
NOTE: The ARM configs are both confusing and too numerous, so I have not
touched those. Also, the kernel-3.5.0-arm.config file seems to be dummy
and winds up with a lot of options unset. The ARM team will need to do
some config option settings, preferrably sooner rather than later.
Perhaps as time goes on, I'll gain a better understanding of what to set
where and how.
josh
11 years, 10 months
What is the earliest x86 64bit CPU we support?
by Tom Callaway
So... what is it?
I think the earliest is the AMD Opteron (2003).
>From a "earliest in each family" perspective, I think the answer is:
AMD: AMD Opteron (2003).
Intel: Intel Xeon (Nocona) (2004)
VIA: VIA Nano (2008)
Excluding Itanium (thank god), are there any other early x86 64bit CPUs
that I'm missing or any that we explicitly no longer support?
~tom
==
Fedora Project
11 years, 10 months
Re: CONFIG_NR_CPUS
by Xose Vazquez Perez
Ruben Kerkhof wrote:
> It's even higher these days:
>
> grep NR_CPUS /boot/config-2.6.32-220.13.1.el6.x86_64
> CONFIG_NR_CPUS=4096
>
> I'm curious, has anyone measured what the memory overhead is of
> keeping NR_CPUS at 512?
> arch/x86/Kconfig says "This is purely to save memory - each supported
> CPU adds approximately eight kilobytes to the kernel image." If that's
> true, 512 cpus use 4MB, something I'm willing to live with on my 64bit
> servers.
https://bugzilla.redhat.com/show_bug.cgi?id=219457
11 years, 10 months
mount --move
by Norman Gaywood
I'm pretty sure that in 3.3.2-6.fc16.x86_64 this sequence worked:
mkdir -p /tmp/testing
cd /tmp/testing/
mkdir -p foo bar
mount -t tmpfs tmpfs foo/
mount --move foo bar/
With 3.3.5-2.fc16.x86_64 the last step gives:
mount: wrong fs type, bad option, bad superblock on /tmp/testing/foo,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Didn't test any kernels between those two.
Is this a bug or feature? Didn't see anything is syslog.
--
Norman Gaywood, Computer Systems Officer
University of New England, Armidale,
NSW 2351, Australia
ngaywood(a)une.edu.au Phone: +61 (0)2 6773 3337
http://mcs.une.edu.au/~norm Fax: +61 (0)2 6773 3312
Please avoid sending me Word or Power Point attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
11 years, 10 months