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, 6 months
Oct. Fedora Kernel Patch Report
by Josh Boyer
Here's this months Fedora kernel report. I intended to get it out
last week, but Greg keeps releasing new stable kernels. Given he's at
KS right now, I'll finally get it written before another release comes
out.
I've skipped the patches we tend to carry for default option changes
and such. If people really want me to keep listing those, I'd be
happy to.
josh
Patches we currently have on top of 3.11.6:
tcp-fix-incorrect-ca_state-in-tail-loss-probe.patch (rhbz 989251)
- Backport of upstream commit 031afe4990a7c9dbff41a3a742c44d3e740ea0a1
fix-buslogic.patch (rhbz 1015558)
- Backport of upstream commit 6541932ea2f7de0b0c5203decf666b143ad5fa33
rt2800usb-slow-down-TX-status-polling.patch (rhbz 984696)
- Still pending upstream. Fixes
https://bugzilla.kernel.org/show_bug.cgi?id=62781
btrfs-relocate-csums-properly-with-prealloc-ext.patch (rhbz 1011714)
- Still pending upstream
fix-radeon-sound.patch (rhbz 1010679)
- Backport of:
062c2e4363451d49ef840232fe65e8bff0dde2a5
e7d12c2f98ae1e68c7298e5028048d150fa553a1
ee0fec312a1c4e26f255955da942562cd8908a4b
b852c985010a77c850b7548d64bbb964ca462b02
- fixes https://bugs.freedesktop.org/show_bug.cgi?id=69675
cpupower-Fix-segfault-due-to-incorrect-getopt_long-a.patch (rhbz 1000439)
- Queued for next upstream release I believe. Fixes a segfault in cpupower
dm-cache-policy-mq_fix-large-scale-table-allocation-bug.patch (rhbz 993744)
- Still pending upstream
0001-iwlwifi-don-t-WARN-on-host-commands-sent-when-firmwa.patch (rhbz 896695)
- Backport of commit 8ca95995e64f5d270889badb3e449dca91106a2b
0002-iwlwifi-don-t-WARN-on-bad-firmware-state.patch (rhbz 896695)
- Still pending upstream
vfio-iommu-Fixed-interaction-of-VFIO_IOMMU_MAP_DMA.patch (rhbz 998732)
- Still pending upstream
iommu-Remove-stack-trace-from-broken-irq-remapping-warning.patch (rhbz 982153)
- Still pending upstream
netfilter-nf_conntrack-use-RCU-safe-kfree-for-conntr.patch
- Backport of commit c13a84a830a208fb3443628773c8ca0557773cc7
rt2800-add-support-for-rf3070.patch (rhbz 974072)
- Actually I'm unsure of what the upstream status on this one is.
elevator-Fix-a-race-in-elevator-switching-and-md.patch
elevator-acquire-q-sysfs_lock-in-elevator_change.patch (rhbz 902012)
- I believe these are both queued for the next upstream release
bonding-driver-alb-learning.patch (rhbz 971893)
- Backport of commit 7eacd03810960823393521063734fc8188446bca
Revert-rt2x00pci-Use-PCI-MSIs-whenever-possible.patch
- Backport of commit dfb6b7c109a7f98d324a759599d1b4616f02c79f
ntp-Make-periodic-RTC-update-more-reliable.patch (rhbz 985522)
- I believe this is queued in John Stultz's tree for 3.13
ansi_cprng-Fix-off-by-one-error-in-non-block-size-request.patch (rhbz
1007690 1009136)
- Fixes CVE-2013-4345
media-cx23885-Fix-TeVii-S471-regression-since-introduction-of-ts2020.patch
(rhbz 963715)
- Backport of commit b43ea8068d2090cb1e44632c8a938ab40d2c7419
iwl3945-better-skb-management-in-rx-path.patch
iwl4965-better-skb-management-in-rx-path.patch (rhbz 977040)
- Backport of commits 45fe142cefa864b685615bcb930159f6749c3667 and
c1de4a9557d9e25e41fc4ba034b9659152205539
ath9k_rx_dma_stop_check.patch (rhbz 892811)
- Fixes some DMA issue on specific hardware. Taken from
https://dev.openwrt.org/browser/trunk/package/mac80211/patches/552-ath9k_...
secure-modules.patch
modsign-uefi.patch
sb-hibernate.patch
sysrq-secure-boot.patch
- Fedora secure boot support.
- Dear Matthew, this is your fault. Run sed already and get a new set out.
keys-expand-keyring.patch
keys-krb-support.patch
keys-x509-improv.patch
keyring-quota.patch
- I believe these are all now queued for 3.13 in James Morris' tree.
10 years
Re: Server product kernel requirements
by Josh Boyer
On Wed, Oct 30, 2013 at 11:12 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/30/2013 11:10 AM, Simo Sorce wrote:
>> On Wed, 2013-10-30 at 10:16 -0400, Josh Boyer wrote:
>>> [ Resend with the right server mailing list address. Sorry
>>> kernel@ people.]
>>>
>>> Hi All,
>>>
>>> I realize the WG is just forming up and you have a lot of other
>>> items to cover for now, but I wanted to get this sent out and
>>> have people start thinking about it sooner rather than later.
>>>
>>> The kernel team is interested in what the Server WG sees as its
>>> requirements for the kernel package. Does today's kernel image
>>> mostly suit those needs already, or are there changes that would
>>> be beneficial?
>>>
>>> While you think about this, please keep in mind that the kernel
>>> team really wants to keep a single kernel package across all 3
>>> products as much as possible. We won't scale to providing
>>> multiple kernel packages or vmlinux binaries for each product.
>>> At the moment, we're essentially looking for a good "core" kernel
>>> package that suits cloud, server, and workstation and then at
>>> repackaging the drivers into subpackages where appropriate.
>>>
>>> If you have changes you'd like to see, please let us know what
>>> they are and the reasoning behind those changes. Hopefully we
>>> can work with all 3 WGs and come up with something suitable for
>>> everyone. Thanks for your time.
>>
>> Personally I think that as long as the kernel is modular and all
>> useful modules are available, the Server WG should not have trouble
>> with it.
>>
>> I guess the installation procedure (hence Anaconda) need to be
>> somewhat customizable so that the server image is by default a lot
>> friendlier to the type of hardware a server gets to use, and the
>> kind of defaults that make more sense for a server vs say desktop
>> or cloud.
>>
>> But I think all this can be built easily above a common kernel.
>>
>
>
> I agree as well. A common kernel is paramount.
OK, good. To be fair, I didn't think there would be many requirements
from the Server WG. Most of the packaging changes will likely be
driven by the Cloud WG. At the moment, it shouldn't be difficult for
Server to install both the small base kernel package and the larger
kernel-drivers subpackage (for example).
At the same time, it would be good to look over what the current
kernel is providing and see if you notice any glaring omissions in
either drivers or settings. Or at the very least, perhaps define what
kind of machines you will be targeting with the Server WG spin.
Massive 4096 multi-cored CPU machines with terabytes of DRAM and
petabytes of storage, or more commodity style hardware used in
heterogeneous environments, etc. Hopefully the impacts to the kernel
there will be minimal, but it would help us understand what you're
shooting for so we can keep it in mind.
josh
10 years
Cloud product kernel requirements
by Josh Boyer
Hi All,
I realize the WG is just forming up and you have a lot of other items
to cover for now, but I wanted to get this sent out and have people
start thinking about it sooner rather than later.
The kernel team has heard in the past that the Cloud group would like
to see something of a more minimal kernel for usage in cloud images.
We'd like to hear the requirements for what this smaller image would
need to cover.
Right now, a default x86_64 kernel package on f20 is ~134MB installed.
Most of that is device drivers installed in /lib/modules/`uname -r`/.
The vmlinux binary is about 5MB and the initramfs (which is created
at install time and can actually vary quite widely depending on
various things) is about 11MB. Drivers can be trimmed to a degree,
but please keep in mind that the kernel is already relatively small
for the functionality it provides. For example, it is not much bigger
than glibc-common (119MB).
So, some caveats to keep in mind while you're thinking about this:
1) We're mostly talking about packaging here, not building a separate
cloud kernel package or vmlinux. The kernel team really wants to have
a single vmlinux across the 3 products if at all possible. We can't
scale to much else.
2) What usecases is the cloud image going to cover? E.g. is it just
virtio stuff, or will it also fit PCI passthru (which then requires
drivers for those PCI devices)?
3) What are the common provisioning requirements that are driving the
size reduction? (See comment about glibc-common. I would think
change is needed in multiple packages, not just the kernel.)
4) Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
Thanks!
josh
10 years
Re: [kernel] Add patch for i.MX6 Utilite device dtb, drop old exynos patch
by Josh Boyer
On Thu, Oct 24, 2013 at 3:29 PM, Peter Robinson
<pbrobinson(a)fedoraproject.org> wrote:
> commit ac67590916a449d1e71a791f6a0c3688251ec074
> Author: Peter Robinson <pbrobinson(a)gmail.com>
> Date: Thu Oct 24 20:29:40 2013 +0100
>
> Add patch for i.MX6 Utilite device dtb, drop old exynos patch
I thought we discussed on IRC that patches were going to get sent to
the list first?
> diff --git a/config-arm-generic b/config-arm-generic
> index 96a95e5..aaa88ee 100644
> --- a/config-arm-generic
> +++ b/config-arm-generic
> @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m
> CONFIG_SMC91X=m
> CONFIG_SMC911X=m
>
> -CONFIG_VIRTIO_CONSOLE=m
> -
Why did this get dropped? The commit message doesn't say.
> # CONFIG_CRYPTO_TEST is not set
> # CONFIG_TRANSPARENT_HUGEPAGE is not set
> # CONFIG_XEN is not set
> diff --git a/kernel.spec b/kernel.spec
> index d1ea97d..19e9e4e 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -675,7 +675,6 @@ Patch15000: nowatchdog-on-virt.patch
> # lpae
> Patch21001: arm-lpae-ax88796.patch
> Patch21004: arm-sound-soc-samsung-dma-avoid-another-64bit-division.patch
> -Patch21005: arm-exynos-mp.patch
>
> # ARM omap
> Patch21010: arm-omap-load-tfp410.patch
> @@ -683,6 +682,10 @@ Patch21010: arm-omap-load-tfp410.patch
> # ARM tegra
> Patch21020: arm-tegra-usb-no-reset-linux33.patch
>
> +# ARM i.MX6
> +# http://www.spinics.net/lists/devicetree/msg08276.html
> +Patch21030: arm-imx6-utilite.patch
The link to the discussion is nice and I appreciate it. Though it
shows that changes have been requested, the patch isn't queued, and it
isn't really fully reviewed.
I don't understand the urgency in adding something that doesn't appear
to be ready according to upstream. Can you elaborate?
josh
10 years
Patch: Fix lpae on exynos5
by John Dulaney
This patch fixes lpae on exynos5 arm processors. LPAE is needed for
virt on arm processors.
--- arch/arm/mach-exynos/mach-exynos5-dt.c 2013-09-02 16:46:10.000000000 -0400
+++ arch/arm/mach-exynos/mach-exynos5-dt.c 2013-10-23 10:35:37.891255087 -0400
@@ -14,7 +14,7 @@
#include <linux/memblock.h>
#include <linux/io.h>
#include <linux/clocksource.h>
-
+#include <linux/dma-mapping.h>
#include <asm/mach/arch.h>
#include <mach/regs-pmu.h>
@@ -23,6 +23,26 @@
#include "common.h"
+static u64 dma_mask64 = DMA_BIT_MASK(64);
+
+static int exynos5250_platform_notifier(struct notifier_block *nb,
+ unsigned long event, void *__dev)
+{
+ struct device *dev = __dev;
+
+ if (event != BUS_NOTIFY_ADD_DEVICE)
+ return NOTIFY_DONE;
+
+ dev->dma_mask = &dma_mask64;
+ dev->coherent_dma_mask = DMA_BIT_MASK(64);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block exynos5250_platform_nb = {
+ .notifier_call = exynos5250_platform_notifier,
+};
+
static void __init exynos5_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -46,6 +66,9 @@
}
}
}
+
+ if (of_machine_is_compatible("samsung,exynos5250"))
+ bus_register_notifier(&platform_bus_type, &exynos5250_platform_nb);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
10 years
Server product kernel requirements
by Josh Boyer
[ Resend with the right server mailing list address. Sorry kernel@ people.]
Hi All,
I realize the WG is just forming up and you have a lot of other items
to cover for now, but I wanted to get this sent out and have people
start thinking about it sooner rather than later.
The kernel team is interested in what the Server WG sees as its
requirements for the kernel package. Does today's kernel image mostly
suit those needs already, or are there changes that would be
beneficial?
While you think about this, please keep in mind that the kernel team
really wants to keep a single kernel package across all 3 products as
much as possible. We won't scale to providing multiple kernel
packages or vmlinux binaries for each product. At the moment, we're
essentially looking for a good "core" kernel package that suits cloud,
server, and workstation and then at repackaging the drivers into
subpackages where appropriate.
If you have changes you'd like to see, please let us know what they
are and the reasoning behind those changes. Hopefully we can work
with all 3 WGs and come up with something suitable for everyone.
Thanks for your time.
josh
10 years, 1 month
Server product kernel requirements
by Josh Boyer
Hi All,
I realize the WG is just forming up and you have a lot of other items
to cover for now, but I wanted to get this sent out and have people
start thinking about it sooner rather than later.
The kernel team is interested in what the Server WG sees as its
requirements for the kernel package. Does today's kernel image mostly
suit those needs already, or are there changes that would be
beneficial?
While you think about this, please keep in mind that the kernel team
really wants to keep a single kernel package across all 3 products as
much as possible. We won't scale to providing multiple kernel
packages or vmlinux binaries for each product. At the moment, we're
essentially looking for a good "core" kernel package that suits cloud,
server, and workstation and then at repackaging the drivers into
subpackages where appropriate.
If you have changes you'd like to see, please let us know what they
are and the reasoning behind those changes. Hopefully we can work
with all 3 WGs and come up with something suitable for everyone.
Thanks for your time.
josh
10 years, 1 month
Fedora Kernel Meeting Minutes for Oct 18, 2013
by Josh Boyer
==============================
#fedora-meeting: Fedora Kernel
==============================
Meeting started by jwb at 18:00:25 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-10-18/fedora-kernel....
.
Meeting summary
---------------
* init (jwb, 18:00:25)
* f18/f19/f20 (jwb, 18:02:16)
* f18 3.11.4 rebase coming soon (jwb, 18:04:25)
* f19/f20 both on 3.11.5 (jwb, 18:04:32)
* ACTION: jwb to add fix for big_keys quota issue to F20 (jwb,
18:06:22)
* ACTION: jforbes will do a mass bug update for f18 asking people to
test with 3.11 (jwb, 18:06:51)
* rawhide (jwb, 18:09:06)
* rawhide at 3.12-rc5-gitX (jwb, 18:12:18)
* ACTION: jwb to look at adding win8 backlight issue patches from 3.13
queue (jwb, 18:12:35)
* open floor (jwb, 18:16:50)
* LINK: https://github.com/kholia/ReproducibleBuilds (nirik,
18:19:59)
Meeting ended at 18:31:45 UTC.
Action Items
------------
* jwb to add fix for big_keys quota issue to F20
* jforbes will do a mass bug update for f18 asking people to test with
3.11
* jwb to look at adding win8 backlight issue patches from 3.13 queue
Action Items, by person
-----------------------
* jforbes
* jforbes will do a mass bug update for f18 asking people to test with
3.11
* jwb
* jwb to add fix for big_keys quota issue to F20
* jwb to look at adding win8 backlight issue patches from 3.13 queue
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jwb (55)
* nirik (22)
* brunowolff (17)
* jforbes (12)
* zodbot (5)
* pbrobinson (2)
* davej (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
10 years, 1 month
