On Thu, Apr 28, 2011 at 01:35:13PM -0400, Jeff Mahoney wrote:

Greg KH: - patches.suse/linux-2.6.29-dont-wait-for-mouse.patch - patches.suse/linux-2.6.29-even-faster-kms.patch - patches.suse/linux-2.6.29-kms-after-sata.patch - patches.suse/linux-2.6.29-jbd-longer-commit-interval.patch - patches.suse/linux-2.6.29-touchkit.patch

Crap, I forgot all about these, I'll go drop them. As Intel never pushed them upstream, they must not care about them so we shouldn't either. Thanks for going through the list of patches, I know it's no fun, but is really needed and appreciated. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:

- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]

We should drop it. Upstream has had file caps by default since Nov 2009. Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59 Cheers, Brandon -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Thursday, April 28, 2011, Jeff Mahoney wrote:

Hi guys -

We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.

Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?

Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later. ... Rafael Wysocki: - patches.arch/x86-mcp51-no-dac [rejected by Alan Cox, Mar 2009]

Dropped. I must admit I had a problem with this one (it's a Tejun's patch to be precise), but finally decided it's better to remain bug compatible with the mainline in that respect and fix the problem in there first if that turns out to be necessary.

- patches.fixes/tg3-fix-default-wol.patch

Submitted upstream. Thanks, Rafael -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Thu, 28 Apr 2011 13:35:13 -0400, Jeff Mahoney wrote:

Jiri Benc: - - patches.suse/panic-on-io-nmi-SLE11-user-space-api.patch [disabled since 2.6.33] [does anyone even use the binary sysctl interface for this?]

Probably not. Deleted from master. Jiri -- Jiri Benc SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Fri, Apr 29, 2011 at 12:17:21AM +0200, Jan Kara wrote:

...

- - patches.suse/raw_device_max_minors_param.diff OK, I'll try to push it upstream (although not sure through whom). Last time I tried to push it, I was told that the driver is going to be removed from upstream altogether but it seems to be still there so I think it may be time to revisit this.

You can send it through me and CC: lkml as I think I pushed back on this last time as I thought this code was going to be removed. As it doesn't look like it ever will, I'll shephard it into Linus's tree if you send it to me. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2011 07:27 PM, Alexander Graf wrote:

On 28.04.2011, at 19:35, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi guys -

We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.

Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?

Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.

Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature

The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.

How should we go here? Do I just remove the patches?

Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.

...

- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic

This one at least made it in already :).

...

[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch

These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.

Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)

PS: olh@suse.de is now ohering@suse.de.

Yep. I got the bounce and forwarded it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+n4ACgkQLPWxlyuTD7JKbACgqAMHpl5BEGAaGd4O+zowLkND vUUAn3bRGeWAaDGxqlyxvSr8m7892Bi4 =2oOk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2011 02:43 PM, Brandon Philips wrote:

On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:

...

Brandon Philips: - - patches.drivers/bnx2-entropy-source.patch - - patches.drivers/e1000-entropy-source.patch - - patches.drivers/e1000e-entropy-source.patch - - patches.drivers/igb-entropy-source.patch - - patches.drivers/ixgbe-entropy-source.patch - - patches.drivers/tg3-entropy-source.patch

Eventually we should provide an entropy gathering daemon as an install option for servers in the installer. Some daemons have been packaged already: #306591: entropy daemons in 11.2

...

- - patches.drivers/tg3-5785-and-57780-asic-revs-not-working.patch

[fixed via 8626d3b4328061f5b82b11ae1d6918a0c3602f42]

Great.

...

- - patches.suse/uvcvideo-ignore-hue-control-for-5986-0241.patch

Deleted fixed in a better way upstream.

Perfect. Thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+qQACgkQLPWxlyuTD7JyyACglwJWpRnjDK3RexqB0i5bkDli 8zwAoJ4PZIytsShks5i6PrCa3zQqyoSQ =P+vk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2011 04:00 PM, Jiri Slaby wrote:

On 04/28/2011 07:35 PM, Jeff Mahoney wrote:

...

Jiri Slaby: - - patches.suse/wireless-no-aes-select

Hi, this doesn't make sense anymore, dropped.

...

- - patches.fixes/iwlwifi-fix-tx-power-configuration-on-3945-and-4965-devices

This was incorrectly disabled during the 2.6.38 merge. The patched code was only heavily moved around, but the fix is still needed. I rebased and reenabled the patch and asked reporters of the corresponding bug to retest (the bnc was reopened). If that works, I'll ping upstream about that...

Ok, thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+v8ACgkQLPWxlyuTD7Lr3gCdEJH2Rme42ezo8cVAyiKSty5w RGsAn3nfSMkUelMVX4fwq+C9oQnZ6pu6 =zokh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2011 06:17 PM, Jan Kara wrote:

On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one...

Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches.

...

- - patches.suse/raw_device_max_minors_param.diff OK, I'll try to push it upstream (although not sure through whom). Last time I tried to push it, I was told that the driver is going to be removed from upstream altogether but it seems to be still there so I think it may be time to revisit this.

...

[ Up for discussion ] - - patches.suse/file-capabilities-disable-by-default.diff [never submitted] - - patches.suse/connector-read-mostly - - patches.suse/ext3-barrier-default - - patches.suse/reiserfs-barrier-default Although I believe the above two would be sane defaults, I kind of feel it might be too late to change the defaults upstream. It would probably generate lots of bug reports of the type "my IO is suddently slower"...

I'm not convinced they actually *are* sane defaults for commodity hardware. Having to flush the entire cache for a barrier is a pretty heavyweight operation, especially with the sizes of caches growing on individual disks. In my own testing it seems like it's faster to disable the write cache and use regular buffer waits rather than flush the cache, but it's been a while since I've done that. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25/DwACgkQLPWxlyuTD7JxEQCfS9XkRUEn/l0PFVv6ffVCee24 8TAAoIJJ0yC0RUmalFz5CQjzWpf6jogX =N0GW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2011 06:19 PM, Jiri Benc wrote:

On Thu, 28 Apr 2011 13:35:13 -0400, Jeff Mahoney wrote:

...

Jiri Benc: - - patches.suse/panic-on-io-nmi-SLE11-user-space-api.patch [disabled since 2.6.33] [does anyone even use the binary sysctl interface for this?]

Probably not. Deleted from master.

Great, thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25/FgACgkQLPWxlyuTD7JlHwCcC+MVFYrzLotvig0yx+BeNvEi EEgAn3w3spxI5UEUFz1oe4PGLHs64fR2 =jcau -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2011 07:53 PM, Alexander Graf wrote:

On 29.04.2011, at 01:38, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 04/28/2011 07:27 PM, Alexander Graf wrote:

...

On 28.04.2011, at 19:35, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi guys -

We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.

Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?

Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.

Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature

The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.

How should we go here? Do I just remove the patches?

Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.

Unfortunately, they haven't been addressed at all FWIW. I also still believe that this is the best way to go - if you don't need to hook into certain subsystems, don't pv-opsizine them :). I just really need to go through the current code again and readjust everything.

Now that we have jump labels, could they be used to fast path the ones that aren't actually used? Wasn't the big impact the indirection used in very fast paths? Or would something like that not actually apply here? I haven't taken a good look at the code, they just seem like a good general way to make optional features nearly free.

...

...

...

- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic

This one at least made it in already :).

...

[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch

These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.

Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)

Yes, it does. I have almost everything in upstream qemu.git, but am missing 2 patches (LPC support, BIOS patch). It's on my todo list for the near future, so stay tuned :). It'd be a shame to lose kvm support in the opensuse kernel just while finally getting all the userspace support upstream.

Ok, that's good enough for me. Ideally, this'll be done before the 12.1 release anyway, right? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk26AnYACgkQLPWxlyuTD7KhhQCeIgoU0YXoyfyPzDkG2be2JTEe Ml4An299YdxQUO9RkLh+A0Fq5B14N39J =AaaL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2011 08:15 PM, Alexander Graf wrote:

On 29.04.2011, at 02:12, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 04/28/2011 07:53 PM, Alexander Graf wrote:

...

On 29.04.2011, at 01:38, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 04/28/2011 07:27 PM, Alexander Graf wrote:

...

On 28.04.2011, at 19:35, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi guys -

We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.

Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?

Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.

Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature

The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.

How should we go here? Do I just remove the patches?

Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.

Unfortunately, they haven't been addressed at all FWIW. I also still believe that this is the best way to go - if you don't need to hook into certain subsystems, don't pv-opsizine them :). I just really need to go through the current code again and readjust everything.

Now that we have jump labels, could they be used to fast path the ones that aren't actually used? Wasn't the big impact the indirection used in very fast paths? Or would something like that not actually apply here? I haven't taken a good look at the code, they just seem like a good general way to make optional features nearly free.

Hrm. I honestly haven't heard of them yet. I can take a look though :).

Great.

...

...

...

...

...

- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic

This one at least made it in already :).

...

[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch

These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.

Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)

Yes, it does. I have almost everything in upstream qemu.git, but am missing 2 patches (LPC support, BIOS patch). It's on my todo list for the near future, so stay tuned :). It'd be a shame to lose kvm support in the opensuse kernel just while finally getting all the userspace support upstream.

Ok, that's good enough for me. Ideally, this'll be done before the 12.1 release anyway, right?

Hopefully :). When is that one due?

12.1 release is 12 Nov 2011, but a more detailed release schedule isn't available yet. Judging by how the timelines have shaken out so far, that probably means 2.6.40, maybe 2.6.41. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk26BJ8ACgkQLPWxlyuTD7Kx2gCgoxHe8n9Wzg9t7M6xAkOMFYvJ z/IAn1I3+2e1b/NcGgOz9xRxalu2r31l =4n9M -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

At Thu, 28 Apr 2011 13:35:13 -0400, Jeff Mahoney wrote:

Takashi Iwai: - - patches.arch/ppc-ipic-suspend-without-83xx-fix [ppc]

I don't remember at all that I fixed it ;) It must be obsoleted, and easy to fix again. Let's drop.

- - patches.arch/x86-hpet-pre-read [disabled since 2.6.37]

Obsoleted. Dropped now.

- - patches.drivers/input-Add-LED-support-to-Synaptics-device

This patch was already submitted twice, but didn't get in by minor reason, IIRC. Anyway, I'm not allowed to work on Synaptics issues any longer. If you have any questions, ask Canonical. (Seriously, I have to answer like this.)

- - patches.drivers/alsa-hda-0019-Increase-default-buffer-size

Still needed as a temporary fix due to transition to systemd. I may add a new kernel config instead in future. Keep this for now. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On 04/28/2011 11:05 PM, Jeff Mahoney wrote:

Suresh Jayaraman: - - patches.suse/sched-revert-latency-defaults [disabled since 2.6.33, after SLE11SP1]

I think it make sense for openSUSE to be close to upstream and given that we have not had any reports since we disabled this, this can be safely dropped.

- - patches.suse/mm-tune-dirty-limits.patch [we may want to revisit per-flavor sysctl files]

Agreed, I think dropping this might have visible impact on performance for users. I think we would need this change but perhaps without kernel changes as suggested by Jeff. So, I plan not drop this until we have a replacement solution in place. Thanks, -- Suresh Jayaraman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]

Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops

There are still no in-kernel users of gup from kernel threads AFAICS. Besides that I think there is no issue in the current upstream because we do not get to handle_mm_fault (and grab_swap_token) path if there is no mm_struct. find_extend_vma will return NULL for (mm == NULL) and so we either go into gate_vma path (which is not handled by the patch and still can be an issue because of pgd_offset_gate) or fail with -EFAULT. The same applies to openSUSE-11.4 and SLES10_SP4_BRANCH branches. If Mel doesn't see anything I would vote for dropping the patch from all supported branches.

- - patches.suse/files-slab-rcu.patch

Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.

- - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore]

Yes we can drop it from SLE11-SP1 and openSUSE-11.4 branches. The zero page has been reintroduced in 2.6.32. The main reason for the above patch was the page fault overhead (coming from allocation and zeroing) during copying from /dev/zero. Now that we have zero page again this is not a case anymore so we do not need any special /dev/zero hacks.

- - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36]

I assume that the patch has been reverted due to changes in the area, right? My impression of the patch is that is highly workload specific. Especially decreasing ZONE_RECLAIM_PRIORITY to 0 is very tricky because it makes reclaim really aggressive. I think this part is highly controversial for upstream. Nevertheless, I quite like the ZONE_RECLAIM_LOCKED part. Although, this can be really subtle because we might end up reclaiming too much if there is really heavy parallel load or multiple high order allocators. I will wait with reverting for Mel but mm-devzero-optimisation.patch is one that can go away for sure. -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2011 10:46 AM, Dr. Werner Fink wrote:

On Thu, Apr 28, 2011 at 09:04:22PM -0400, Jeff Mahoney wrote:

...

On 04/28/2011 07:46 PM, Jeff Mahoney wrote:

...

On 04/28/2011 06:17 PM, Jan Kara wrote:

...

On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one...

Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches.

Actually, it's even easier than this. The sysctl tool loads values from the filenames it's passed. That generally means just /etc/sysctl.conf but we could modify boot.sysctl to load a per-kernel sysctl.conf first. It'd probably go into /boot, just like we do for .config and System.map already. There's a /etc/sysctl.d on my system, but it's part of systemd and loads after /etc/sysctl.conf.

For now, we'd only need a sysctl.conf-2.6.39-rc4-12-desktop that contains the following line: vm.dirty_ratio = 20

There were two other things related to KERNEL_DESKTOP: Preemption and cgroups. Since systemd requires cgroups, they're now enabled everywhere anyway. We can probably remember to keep CONFIG_PREEMPT=y on the desktop flavors on our own, or perhaps create a mechanism to check that certain options are enabled on certain flavors.

-Jeff

[CC'ing Werner to comment on the idea]

I'd like to see something

/lib/modules/<kernel-version>/sysctl.conf

or

/boot/sysctl.<kernel-version>

but /boot could be an own paritition whereas /lib is not.

I'm not sure if we're "allowed" to put additional files in /lib/modules/$UNAME but it seems like the best way to do it. One of my concerns is net-booting a particular flavor, where /boot probably won't be populated as it should be. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk260oQACgkQLPWxlyuTD7KqlgCfdGICYiAHbaCiXBogvK2/aiGj 3oQAn3uyu8Lzn96dKtgaKPtagBs/3FMW =yhBp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Fri, Apr 29, 2011 at 08:38:44AM +0200, Marcus Meissner wrote:

On Thu, Apr 28, 2011 at 07:40:08PM -0400, Jeff Mahoney wrote:

...

On 04/28/2011 02:50 PM, Brandon Philips wrote:

...

On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:

...

- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]

We should drop it. Upstream has had file caps by default since Nov 2009.

Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59

In doing a zypper dup today, I saw that something is looking at /proc/cmdline for "file_caps" as part of SuSEconfig running. We should probably figure out what that is.

The SuSEconfig permissions module, it decides on whether to handle file caps setting or not depending on the kernel.

Ludwig wants a patch to detect this for years in the mainline kernel, but it is not there yet.

Can you please take care that such a method is exposed by mainline? (file_caps might be disabled or enabled, we should handle both cases and detect it from the kernel.)

The patch doing this in the kernel is queued up to be accepted for the .40 kernel release, so perhaps I should also add it to our tree now so that FACTORY can be converted over to using it and this can be dropped? If so, just let me know and I will go add it as it is in my upstream kernel tree already. And it was my fault that it took so long to get accepted for the past 6+ months, sorry, it got lost in my patch queue :( thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Thu 28-04-11 19:46:04, Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

...

On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one... Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and

On 04/28/2011 06:17 PM, Jan Kara wrote: then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches. Yeah, it would be easiest if we could do such parameter tuning without a kernel patch.

...

...

[ Up for discussion ] - - patches.suse/file-capabilities-disable-by-default.diff [never submitted] - - patches.suse/connector-read-mostly - - patches.suse/ext3-barrier-default - - patches.suse/reiserfs-barrier-default Although I believe the above two would be sane defaults, I kind of feel it might be too late to change the defaults upstream. It would probably generate lots of bug reports of the type "my IO is suddently slower"...

I'm not convinced they actually *are* sane defaults for commodity hardware. Having to flush the entire cache for a barrier is a pretty heavyweight operation, especially with the sizes of caches growing on individual disks. In my own testing it seems like it's faster to disable the write cache and use regular buffer waits rather than flush the cache, but it's been a while since I've done that. I guess it depends on the drive and the load. I remember Tejun did some testing of this when he was working on the barrier code and found out that write caches are useful on normal SATA drives. The drive can still do more reordering of IO when it has write caches enabled. But I agree that e.g. for fsync heavy workloads, turning off write caches may well be the faster option.

Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Thu, Apr 28, 2011 at 01:35:13PM -0400, Jeff Mahoney wrote:

Tony Jones: - - patches.suse/kdump-dump_after_notifier.patch not my patch but dead; removed

- - patches.fixes/oprofile_bios_ctr.patch upstream in alt. form, should have removed it previously, sorry; removed

-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Tue 10-05-11 10:40:37, Mel Gorman wrote:

On Fri, Apr 29, 2011 at 12:28:50PM +0200, Michal Hocko wrote:

...

On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]

...

Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops

There are still no in-kernel users of gup from kernel threads AFAICS. Besides that I think there is no issue in the current upstream because we do not get to handle_mm_fault (and grab_swap_token) path if there is no mm_struct. find_extend_vma will return NULL for (mm == NULL) and so we either go into gate_vma path (which is not handled by the patch and still can be an issue because of pgd_offset_gate) or fail with -EFAULT.

The same applies to openSUSE-11.4 and SLES10_SP4_BRANCH branches. If Mel doesn't see anything I would vote for dropping the patch from all supported branches.

That patch belongs to an SGI developer so there is a possibility that they have an RDMA driver or MPI accelerator that was doing direct writes to userspace after pinning the page with get_user_pages(). GPFS could also be doing weird things from kernel threads and pinning pages for IO a kernel thread context.

Then we should keep the patch. We shouldn't risk any "regression" even though they might be bugs in the external code. Thanks for the clarification I missed that 3rd party modules can really matter here. [...]

...

...

- - patches.suse/files-slab-rcu.patch

Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.

Drop it unless there is a known specific use case it helps. There is now a whole host of other VFS black magic merged to mainline and it improves open/close performance in other ways. Slab-destroy-by-rcu means there is a variable amount of time spent freeing slab objects. Many users probably don't care, but realtime people have complained about variable latency when freeing slab objects before and this is the kind of thing that can surprise them.

Jack should have pinged Nick about this one so I would rather wait for what he comes with.

...

...

- - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore]

Yes we can drop it from SLE11-SP1 and openSUSE-11.4 branches. The zero page has been reintroduced in 2.6.32. The main reason for the above patch was the page fault overhead (coming from allocation and zeroing) during copying from /dev/zero. Now that we have zero page again this is not a case anymore so we do not need any special /dev/zero hacks.

Sure.

Removed from SLE11-SP1 (SP2 will get it automatically), openSUSE.11.3, openSUSE.11.4 and master branches.

...

...

- - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36]

I assume that the patch has been reverted due to changes in the area, right?

It's not clear. I think it might have been dropped due to conflicts and there was no motivation to keep it updated.

...

My impression of the patch is that is highly workload specific.

Extremely so.

...

Especially decreasing ZONE_RECLAIM_PRIORITY to 0 is very tricky because it makes reclaim really aggressive. I think this part is highly controversial for upstream.

It would only make sense on a machine running threads that were tightly bound to their NUMA node which will probably only be tree on HPC configurations. For things like mail servers running on Nehalem with large NUMA distances, this patch could have very surprising results.

...

Nevertheless, I quite like the ZONE_RECLAIM_LOCKED part. Although, this can be really subtle because we might end up reclaiming too much if there is really heavy parallel load or multiple high order allocators.

Yes.

A consequence of removing it is that a number of parallel allocator requests that happen at the same time dump all the memory of a node. Worse, they could start reclaiming each others memory in the node which would manifest as unexpected stalls at unpredictable times. This is true for normal reclaim of course but in __zone_reclaim it's potentially worse as it's focusing on clean pages.

...

I will wait with reverting for Mel but mm-devzero-optimisation.patch is one that can go away for sure.

Ditch it. It is likely to adversely affect common workloads that are heavily file based.

OK. I will keep it for for SLE11-SP[12] because we had an L3 request for it and it fixed a real problem that our customer saw and nobody complained about massive zone reclaim so far. I will remove it from other branches (master, openSUSE.11.[34]). Thanks -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Tue 10-05-11 10:40:37, Mel Gorman wrote: [...]

...

...

...

- - patches.suse/files-slab-rcu.patch

Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.

Drop it unless there is a known specific use case it helps. There is now a whole host of other VFS black magic merged to mainline and it improves open/close performance in other ways. Slab-destroy-by-rcu means there is a variable amount of time spent freeing slab objects. Many users probably don't care, but realtime people have complained about variable latency when freeing slab objects before and this is the kind of thing that can surprise them.

Jack should have pinged Nick about this one so I would rather wait for what he comes with. Yes, I've pinged him but he didn't reply so far. So I'd just drop the

On Tue 10-05-11 14:27:43, Michal Hocko wrote: patch. If Nick wants to pursue this further, he has the patch in his mailbox. And if he doesn't, we don't have a real need to do so... Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Thu, 28 Apr 2011 11:50:11 -0700 Brandon Philips wrote:

On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:

...

- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]

We should drop it. Upstream has had file caps by default since Nov 2009.

Apparently this did not happen. How do I enable file_caps now that the SuSEconfig.permissions module needs them? See https://bugzilla.novell.com/show_bug.cgi?id=694550 for the gory details. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/18/2011 11:25 AM, Bruno Friedmann wrote:

On 05/18/2011 03:23 PM, Stefan Seyfried wrote:

...

On Thu, 28 Apr 2011 11:50:11 -0700 Brandon Philips wrote:

...

On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:

...

- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]

We should drop it. Upstream has had file caps by default since Nov 2009.

Apparently this did not happen. How do I enable file_caps now that the SuSEconfig.permissions module needs them?

See https://bugzilla.novell.com/show_bug.cgi?id=694550 for the gory details.

Unfortunately not available for everybody! normal ? If nothing is pure full secret can you open it ?

All set. Bugzilla defaults to locking down bug reports that are filed under Security. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3UFp4ACgkQLPWxlyuTD7LbBQCfUbPyM5jfLfyQ1LxE5mPFRZSv EC0An1Dslv5ioDbO0GTqfsFNo4kNaVh+ =MffB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2011 11:36 AM, Greg KH wrote:

On Fri, Apr 29, 2011 at 08:38:44AM +0200, Marcus Meissner wrote:

...

On Thu, Apr 28, 2011 at 07:40:08PM -0400, Jeff Mahoney wrote:

...

On 04/28/2011 02:50 PM, Brandon Philips wrote:

...

On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:

...

- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]

We should drop it. Upstream has had file caps by default since Nov 2009.

Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59

In doing a zypper dup today, I saw that something is looking at /proc/cmdline for "file_caps" as part of SuSEconfig running. We should probably figure out what that is.

The SuSEconfig permissions module, it decides on whether to handle file caps setting or not depending on the kernel.

Ludwig wants a patch to detect this for years in the mainline kernel, but it is not there yet.

Can you please take care that such a method is exposed by mainline? (file_caps might be disabled or enabled, we should handle both cases and detect it from the kernel.)

The patch doing this in the kernel is queued up to be accepted for the .40 kernel release, so perhaps I should also add it to our tree now so that FACTORY can be converted over to using it and this can be dropped?

If so, just let me know and I will go add it as it is in my upstream kernel tree already.

And it was my fault that it took so long to get accepted for the past 6+ months, sorry, it got lost in my patch queue :(

This has now become interesting, it seems. I just noticed that /bin/ping has capabilities set and is no longer suid root on two of my factory machines. Consequently, it's not working unless I boot with file_caps on the command line. As to whether or not it's currently available, wouldn't something like the attached program work for that? I copied the security.capability attribute from /bin/ping to a test program (as root) and it gives me val=0 on my system without file_caps and val=1 on my system with it when I run it with an unprivileged user. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3cYzgACgkQLPWxlyuTD7LV7QCfbRfX7cWwOfuprKSJ8IoPLInk d48AoKezMiMblfX6aw+UySwtGJmUPEe4 =7yjj -----END PGP SIGNATURE-----

Jeff Mahoney wrote:

This has now become interesting, it seems. I just noticed that /bin/ping has capabilities set and is no longer suid root on two of my factory machines. Consequently, it's not working unless I boot with file_caps on the command line.

Yes, in anticipation of getting rid of the patch that disables fscaps by default I've switched the default from file caps off to file caps on in chkstat. The patch that introduces /sys/kernel/fscaps is now upstream (thanks Greg). So as soon as someone submits the next upstream kernel update to Factory chkstat can decide whether to use fscaps or suid dynamically. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org