kernel October 2013

kernel@lists.fedoraproject.org

20 participants
15 discussions

fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg 04 Jun '15

04 Jun '15

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

5 9

Oct. Fedora Kernel Patch Report
by Josh Boyer 02 Dec '13

02 Dec '13

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_rx… 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.

3 2

Re: Server product kernel requirements
by Josh Boyer 06 Nov '13

06 Nov '13

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

6 17

Cloud product kernel requirements
by Josh Boyer 06 Nov '13

06 Nov '13

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

8 11

Re: [kernel] Add patch for i.MX6 Utilite device dtb, drop old exynos patch
by Josh Boyer 06 Nov '13

06 Nov '13

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

3 9

Patch: Fix lpae on exynos5
by John Dulaney 05 Nov '13

05 Nov '13

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); }

3 5

Server product kernel requirements
by Josh Boyer 30 Oct '13

30 Oct '13

[ 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

2 1

Server product kernel requirements
by Josh Boyer 30 Oct '13

30 Oct '13

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

1 0

*********** MASS BUG UPDATE **************
by Jóhann B. Guðmundsson 19 Oct '13

19 Oct '13

Seriously wtf and good morning to you too. Next time think these things through... JBG

2 1

Fedora Kernel Meeting Minutes for Oct 18, 2013
by Josh Boyer 18 Oct '13

18 Oct '13

============================== #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.20… . 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel October 2013