[opensuse-kernel] Merging kernel-desktop back to kernel-default (fate#319416)
Hi, since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following: - Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 03/09/15 19:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
Michal
Why is always necessary to change things when things are running smoothly? Why? In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users? BC -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 04 Sep 2015 09:33:10 +0200, Basil Chupin wrote:
On 03/09/15 19:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
Michal
Why is always necessary to change things when things are running smoothly? Why?
Because having two flavors costs very much: it costs double for maintenance, and it costs double for resources. As you might know, the kernel package is neither small nor trivial package.
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users?
It's a technical detail, and we care not to break things. That's why we're *discussing* here now. If you have an enough technical reason not to do that (or doing other way), please let us know. Your comment above looks more like a FUD without actual evaluation. General speaking, this change will give more merits to users, too. The situation where we have default and desktop flavors is weird. Why desktop flavor is used as default installation while there is default flavor? It was intended as a short-time stop-gap, but this was dragged too long. So, reducing such a confusion is good for users. Also, changing from built-in to modules will give more merits. In that way, you can update the functionality more easily. For example, with the current desktop flavor, if you want to change something in ext4, you'd have to replace the whole kernel because it's built in. If it's a module, you can just install a KMP for testing and uninstall for reverting. Again, such built-in config was also considered as a temporary stop gap at the time we aimed more for speed on a slow Netbooks, and this won't justify any longer. So, think this action from another POV: it's a good chance to "fix" such weirdness. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 04/09/15 17:53, Takashi Iwai wrote:
On 03/09/15 19:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
Michal Why is always necessary to change things when things are running smoothly? Why? Because having two flavors costs very much: it costs double for
On Fri, 04 Sep 2015 09:33:10 +0200, Basil Chupin wrote: maintenance, and it costs double for resources. As you might know, the kernel package is neither small nor trivial package.
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users? It's a technical detail, and we care not to break things. That's why we're *discussing* here now. If you have an enough technical reason not to do that (or doing other way), please let us know. Your comment above looks more like a FUD without actual evaluation.
I am not aware of any rule regarding discussion which disallows questions being asked. Or is asking questions a no-no only if it has anything to do with openSUSE?
General speaking, this change will give more merits to users, too. The situation where we have default and desktop flavors is weird. Why desktop flavor is used as default installation while there is default flavor? It was intended as a short-time stop-gap, but this was dragged too long. So, reducing such a confusion is good for users.
Also, changing from built-in to modules will give more merits. In that way, you can update the functionality more easily. For example, with the current desktop flavor, if you want to change something in ext4, you'd have to replace the whole kernel because it's built in. If it's a module, you can just install a KMP for testing and uninstall for reverting.
Again, such built-in config was also considered as a temporary stop gap at the time we aimed more for speed on a slow Netbooks, and this won't justify any longer.
So, think this action from another POV: it's a good chance to "fix" such weirdness.
My question,"Why?", is simply asking why change things when: 1) there was a legitimate reason for creating another flavour of the kernel - the -desktop - with its special settings (I refer,eg, to the 'CONFIG_HZ=1000' in particular which I had to apply in my early compilations of the kernel to get better performance from it for my desktop) when there already were the PAE kernel, the Default kernel, and then the XEN kernel and the other to cater for the mini computer owners (cannot remember its name); and 2) nobody complained for years about compiling and maintaining and providing all the variants of the kernel. But suddenly now it has become a "burden" and a strain on resources! And yet we see almost a daily release of an almost unusable piece of software called Tumbleweed which is 4.3GB big and must take a huge amount of resources to produce - but that's OK, right? Keeping the above in mind is the reason why I asked another question which I will now repeat and quote in full - please forgive!: In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users? BC -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 07 Sep 2015 09:43:54 +0200, Basil Chupin wrote:
On 04/09/15 17:53, Takashi Iwai wrote:
On 03/09/15 19:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
Michal Why is always necessary to change things when things are running smoothly? Why? Because having two flavors costs very much: it costs double for
On Fri, 04 Sep 2015 09:33:10 +0200, Basil Chupin wrote: maintenance, and it costs double for resources. As you might know, the kernel package is neither small nor trivial package.
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users? It's a technical detail, and we care not to break things. That's why we're *discussing* here now. If you have an enough technical reason not to do that (or doing other way), please let us know. Your comment above looks more like a FUD without actual evaluation.
I am not aware of any rule regarding discussion which disallows questions being asked. Or is asking questions a no-no only if it has anything to do with openSUSE?
Well, the tone of the sentence "why create avoidable angst and gnashing of teeth by users?" doesn't sound like a pure (preferably technical) question but rather offensive. If it were a neutral tone, it would have been received differently.
General speaking, this change will give more merits to users, too. The situation where we have default and desktop flavors is weird. Why desktop flavor is used as default installation while there is default flavor? It was intended as a short-time stop-gap, but this was dragged too long. So, reducing such a confusion is good for users.
Also, changing from built-in to modules will give more merits. In that way, you can update the functionality more easily. For example, with the current desktop flavor, if you want to change something in ext4, you'd have to replace the whole kernel because it's built in. If it's a module, you can just install a KMP for testing and uninstall for reverting.
Again, such built-in config was also considered as a temporary stop gap at the time we aimed more for speed on a slow Netbooks, and this won't justify any longer.
So, think this action from another POV: it's a good chance to "fix" such weirdness.
My question,"Why?", is simply asking why change things when:
1) there was a legitimate reason for creating another flavour of the kernel - the -desktop - with its special settings (I refer,eg, to the 'CONFIG_HZ=1000' in particular which I had to apply in my early compilations of the kernel to get better performance from it for my desktop) when there already were the PAE kernel, the Default kernel, and then the XEN kernel and the other to cater for the mini computer owners (cannot remember its name); and
The changes we're considering are, more exactly, not "drop desktop flavor" but rather "merge desktop and default flavors to a single default flavor". The key configurations about the performance are more aligned to the current desktop flavor, so far. In anyway, your observation about CONFIG_HZ=1000 is a myth nowadays. CONFIG_HZ=1000 is mostly superfluous when combined with CONFIG_PREEMPT. Most of other distros take CONFIG_HZ=250, IIRC. As already explained, the setup was introduced at the time we worked on Meego on Netbooks. The boot speed was the first priority, and the response on the slow machine was the second. The last comes to performance. But this was the past experience, and doesn't match with the recent machines at all. We'd need to revise these setups, sooner or later.
2) nobody complained for years about compiling and maintaining and providing all the variants of the kernel.
No, most of kernel developers have been complaining about this duplication since the introduction of desktop flavor. It didn't come up to user list so often just because there were mostly on internal kernel ML. No one ever liked desktop flavor, but this hack was kept only because of laziness (*shame*).
But suddenly now it has become a "burden" and a strain on resources! And yet we see almost a daily release of an almost unusable piece of software called Tumbleweed which is 4.3GB big and must take a huge amount of resources to produce - but that's OK, right?
The build of kernel takes lots of resources, both of CPU and space. And this happens on each kernel branch and each user branch. Of course there are lots of other resource hogs in other packages, but the significant difference is that kernel is the most frequently modified packages ever. Reduction of one kernel flavor will help for kernel developers, not only for users, a lot.
Keeping the above in mind is the reason why I asked another question which I will now repeat and quote in full - please forgive!:
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users?
I hope my previous and this replies answer your questions enough. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
I hope my previous and this replies answer your questions enough.
Takashi
Hi Takashi. I would like to emboss with a special marker, the excellence in tone and content. This recenter the debate about what was always the content of this mailing list. Regards. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 07/09/15 18:24, Takashi Iwai wrote:
On Mon, 07 Sep 2015 09:43:54 +0200, Basil Chupin wrote:
On 04/09/15 17:53, Takashi Iwai wrote:
On 03/09/15 19:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
Michal Why is always necessary to change things when things are running smoothly? Why? Because having two flavors costs very much: it costs double for
On Fri, 04 Sep 2015 09:33:10 +0200, Basil Chupin wrote: maintenance, and it costs double for resources. As you might know, the kernel package is neither small nor trivial package.
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users? It's a technical detail, and we care not to break things. That's why we're *discussing* here now. If you have an enough technical reason not to do that (or doing other way), please let us know. Your comment above looks more like a FUD without actual evaluation.
I am not aware of any rule regarding discussion which disallows questions being asked. Or is asking questions a no-no only if it has anything to do with openSUSE? Well, the tone of the sentence "why create avoidable angst and gnashing of teeth by users?" doesn't sound like a pure (preferably technical) question but rather offensive. If it were a neutral tone, it would have been received differently.
General speaking, this change will give more merits to users, too. The situation where we have default and desktop flavors is weird. Why desktop flavor is used as default installation while there is default flavor? It was intended as a short-time stop-gap, but this was dragged too long. So, reducing such a confusion is good for users.
Also, changing from built-in to modules will give more merits. In that way, you can update the functionality more easily. For example, with the current desktop flavor, if you want to change something in ext4, you'd have to replace the whole kernel because it's built in. If it's a module, you can just install a KMP for testing and uninstall for reverting.
Again, such built-in config was also considered as a temporary stop gap at the time we aimed more for speed on a slow Netbooks, and this won't justify any longer.
So, think this action from another POV: it's a good chance to "fix" such weirdness.
My question,"Why?", is simply asking why change things when:
1) there was a legitimate reason for creating another flavour of the kernel - the -desktop - with its special settings (I refer,eg, to the 'CONFIG_HZ=1000' in particular which I had to apply in my early compilations of the kernel to get better performance from it for my desktop) when there already were the PAE kernel, the Default kernel, and then the XEN kernel and the other to cater for the mini computer owners (cannot remember its name); and The changes we're considering are, more exactly, not "drop desktop flavor" but rather "merge desktop and default flavors to a single default flavor". The key configurations about the performance are more aligned to the current desktop flavor, so far.
In anyway, your observation about CONFIG_HZ=1000 is a myth nowadays. CONFIG_HZ=1000 is mostly superfluous when combined with CONFIG_PREEMPT. Most of other distros take CONFIG_HZ=250, IIRC.
Pardon moi, but I don't really care what the other distros use or put up with. I care about openSUSE
As already explained, the setup was introduced at the time we worked on Meego on Netbooks. The boot speed was the first priority, and the response on the slow machine was the second. The last comes to performance. But this was the past experience, and doesn't match with the recent machines at all. We'd need to revise these setups, sooner or later.
2) nobody complained for years about compiling and maintaining and providing all the variants of the kernel. No, most of kernel developers have been complaining about this duplication since the introduction of desktop flavor. It didn't come up to user list so often just because there were mostly on internal kernel ML. No one ever liked desktop flavor, but this hack was kept only because of laziness (*shame*).
But suddenly now it has become a "burden" and a strain on resources! And yet we see almost a daily release of an almost unusable piece of software called Tumbleweed which is 4.3GB big and must take a huge amount of resources to produce - but that's OK, right? The build of kernel takes lots of resources, both of CPU and space. And this happens on each kernel branch and each user branch. Of course there are lots of other resource hogs in other packages, but the significant difference is that kernel is the most frequently modified packages ever. Reduction of one kernel flavor will help for kernel developers, not only for users, a lot.
OK, I accept that it does take up some computer and human resources to produce another version of anything in which case then produce a single kernel which still contains what was included in the *-desktop kernel. For example, why reduce the CONFIG_HZ=1000 down to '*=250'? It doesn't require any effort or additional resources to keep this figure at 1000 Hz so why reduce it down to 250 - except for the reason of stubbornness? Further discussion in this thread shows that people may notice the difference in performance because of this change - so, for Chrissake, why make the change? Leave the CONFIG_HZ=1000 alone.
Keeping the above in mind is the reason why I asked another question which I will now repeat and quote in full - please forgive!:
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users? I hope my previous and this replies answer your questions enough.
As you would have gathered by now, the answer to this is NO :-) . BC -- Using openSUSE 13.2, KDE 4.14.9 & kernel 4.2.2-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 04.10.2015 um 13:29 schrieb Basil Chupin:
OK, I accept that it does take up some computer and human resources to produce another version of anything in which case then produce a single kernel which still contains what was included in the *-desktop kernel. For example, why reduce the CONFIG_HZ=1000 down to '*=250'? It doesn't require any effort or additional resources to keep this figure at 1000 Hz so why reduce it down to 250 - except for the reason of stubbornness?
Because HZ=250 will perform better in almost all use cases.
Further discussion in this thread shows that people may notice the difference in performance because of this change
Yes. Performance will improve with HZ=250.
- so, for Chrissake, why make the change? Leave the CONFIG_HZ=1000 alone.
Do you have any facts to back your claim that HZ=1000 benefits your use case? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun, 2015-10-04 at 22:29 +1100, Basil Chupin wrote:
Further discussion in this thread shows that people may notice the difference in performance because of this change - so, for Chrissake, why make the change? Leave the CONFIG_HZ=1000 alone.
We decided to leave PREEMPT alone, because that really will make a difference for some. Tick frequency is another matter entirely. Tick frequency was a major factor in the old O(1) scheduler, as that determined scheduling granularity given competing tasks of equal priority, but that has not been the case for a very long time. CFS does not necessarily context switch upon every timer interrupt. It will do some bean counting, will add a bit of overhead, and may context switch, but the vast majority of the time, preemption is wakeup driven. Fact is that we chew up quite a pile of cycles _over_ scheduling in PREEMPT kernels in the general case. If you want something to fret over, fret over those very real squandered joules :) -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-04 14:51, Mike Galbraith wrote:
On Sun, 2015-10-04 at 22:29 +1100, Basil Chupin wrote:
Further discussion in this thread shows that people may notice the difference in performance because of this change - so, for Chrissake, why make the change? Leave the CONFIG_HZ=1000 alone.
We decided to leave PREEMPT alone, because that really will make a difference for some. Tick frequency is another matter entirely.
Tick frequency was a major factor in the old O(1) scheduler, as that determined scheduling granularity given competing tasks of equal priority, but that has not been the case for a very long time. CFS does
I remember old discussions, perhaps by xine devs, that the tick frequency has some influence on these multimedia applications. I do not know if this will be still true. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYRyxEACgkQtTMYHG2NR9X0GwCgkhwJTOzQsIvAhIibzCn+bCk6 itcAoJbsVqy2yMIl8EEX9K9T/FLz4Gds =WVtX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 2015-10-05 at 02:57 +0200, Carlos E. R. wrote:
On 2015-10-04 14:51, Mike Galbraith wrote:
On Sun, 2015-10-04 at 22:29 +1100, Basil Chupin wrote:
Further discussion in this thread shows that people may notice the difference in performance because of this change - so, for Chrissake, why make the change? Leave the CONFIG_HZ=1000 alone.
We decided to leave PREEMPT alone, because that really will make a difference for some. Tick frequency is another matter entirely.
Tick frequency was a major factor in the old O(1) scheduler, as that determined scheduling granularity given competing tasks of equal priority, but that has not been the case for a very long time. CFS does
I remember old discussions, perhaps by xine devs, that the tick frequency has some influence on these multimedia applications.
I don't see how, userspace defines HZ = 100. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-05 03:23, Mike Galbraith wrote:
On Mon, 2015-10-05 at 02:57 +0200, Carlos E. R. wrote:
I remember old discussions, perhaps by xine devs, that the tick frequency has some influence on these multimedia applications.
I don't see how, userspace defines HZ = 100.
Then it's ok :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYR0yIACgkQtTMYHG2NR9XVUQCfQ4WRONh/28As7RmFybnIT5eg PvwAnRDU4iwkc6wBcq1RG/l8pyJFTcw0 =RuDT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 2015-09-07 at 17:43 +1000, Basil Chupin wrote:
1) there was a legitimate reason for creating another flavour of the kernel - the -desktop - with its special settings (I refer,eg, to the 'CONFIG_HZ=1000' in particular which I had to apply in my early compilations of the kernel to get better performance from it for my desktop) when there already were the PAE kernel, the Default kernel, and then the XEN kernel and the other to cater for the mini computer owners (cannot remember its name); and
If PREEMPT remains enabled, I don't see why there would be any noticeable benefit from HZ=1000 vs 250. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, Sep 4, 2015 at 3:33 AM, Basil Chupin <blchupin@iinet.net.au> wrote:
On 03/09/15 19:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
Michal
Why is always necessary to change things when things are running smoothly? Why?
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users?
BC
Basil, As I understand it all the kernel modules are copied to initrd (initial ramdisk) so they are available at boot time without the use of any hardware drivers. Thus built-in drivers are not needed in the standard openSUSE boot sequence. So the question is why support built-in drivers when they are not needed in the supported openSUSE boot sequence. Greg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 05/09/15 06:31, Greg Freemyer wrote:
On Fri, Sep 4, 2015 at 3:33 AM, Basil Chupin <blchupin@iinet.net.au> wrote:
On 03/09/15 19:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
Michal
Why is always necessary to change things when things are running smoothly? Why?
In your own words, "What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts.....", so why create avoidable angst and gnashing of teeth by users?
BC Basil,
As I understand it all the kernel modules are copied to initrd (initial ramdisk) so they are available at boot time without the use of any hardware drivers. Thus built-in drivers are not needed in the standard openSUSE boot sequence.
So the question is why support built-in drivers when they are not needed in the supported openSUSE boot sequence.
Greg
Sorry Greg but your response does not quite gel with what the OP stated. If what you say is correct then why all the fuss about bringing the subject up in the first place? BC -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 03 Sep 2015 11:26:24 +0200, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus. What we will definitely lose are the various builtin driver choices of the -desktop flavor. Merging these with the SLE kernel configs would constantly result in conflicts, while the boot time gains are negligible. And we will lose the placebo effect of the kernel having "desktop" in its name.
I think one thing was missing in the previous discussion: the migration of KMP. kernel-module-subpackage already has: %if %1 == "default" Obsoletes: %{-n*}-trace so a similar hack should be added there. (BTW, having only obsoletes tag is enough? Will zypper pull default-kmp when updating from desktop automatically even without provides tag?) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-09-04 10:20, Takashi Iwai wrote:
I think one thing was missing in the previous discussion: the migration of KMP. kernel-module-subpackage already has:
%if %1 == "default" Obsoletes: %{-n*}-trace
so a similar hack should be added there.
Good point.
(BTW, having only obsoletes tag is enough? Will zypper pull default-kmp when updating from desktop automatically even without provides tag?)
Hard to tell, but the Obsoletes: is probably the lesser evil. The rationale is that KMPs are often selected by either pci aliases (drivers) or by a userspace package (xen, virtualbox). So in most cases the new -default KMP is installed either way and we just need to silently remove the old -desktop KMP. A potential problem is when a KMP is dropped, since the kernel spec file only obsoletes KMPs of its own flavor. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 04 Sep 2015 10:41:42 +0200, Michal Marek wrote:
On 2015-09-04 10:20, Takashi Iwai wrote:
I think one thing was missing in the previous discussion: the migration of KMP. kernel-module-subpackage already has:
%if %1 == "default" Obsoletes: %{-n*}-trace
so a similar hack should be added there.
Good point.
(BTW, having only obsoletes tag is enough? Will zypper pull default-kmp when updating from desktop automatically even without provides tag?)
Hard to tell, but the Obsoletes: is probably the lesser evil. The rationale is that KMPs are often selected by either pci aliases (drivers) or by a userspace package (xen, virtualbox). So in most cases the new -default KMP is installed either way and we just need to silently remove the old -desktop KMP.
Well, if it's something like a generic framework (like BFQ iosched module), there is no tied device or alias. It's a corner case, though. But I'm not sure which is safer (less breaking) in the end.
A potential problem is when a KMP is dropped, since the kernel spec file only obsoletes KMPs of its own flavor.
Right, this needs to be also covered in kernel-binary.rpm.in. How messy... Now thinking of the KMP issues again: by obsoleting, the old desktop-kmp gets removed. Then this will break the previous kernel boot? Or, KMP isn't covered in anyway for multi-boot? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-09-04 11:11, Takashi Iwai wrote:
Now thinking of the KMP issues again: by obsoleting, the old desktop-kmp gets removed. Then this will break the previous kernel boot? Or, KMP isn't covered in anyway for multi-boot?
The kernel-default package will also obsolete kernel-desktop. Agreed that it does not go well with multiversion. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 04 Sep 2015 11:13:54 +0200, Michal Marek wrote:
On 2015-09-04 11:11, Takashi Iwai wrote:
Now thinking of the KMP issues again: by obsoleting, the old desktop-kmp gets removed. Then this will break the previous kernel boot? Or, KMP isn't covered in anyway for multi-boot?
The kernel-default package will also obsolete kernel-desktop.
Ah, of course, you're right -- problem solved (wrongly :)
Agreed that it does not go well with multiversion.
Yeah, if all the previous kernels are really gone, it looks risky. Maybe we can drop Obsolete tag but only give Provides tag, supposing the multi-version allows it? Need to test... Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-09-04 11:21, Takashi Iwai wrote:
On Fri, 04 Sep 2015 11:13:54 +0200, Michal Marek wrote:
On 2015-09-04 11:11, Takashi Iwai wrote:
Now thinking of the KMP issues again: by obsoleting, the old desktop-kmp gets removed. Then this will break the previous kernel boot? Or, KMP isn't covered in anyway for multi-boot?
The kernel-default package will also obsolete kernel-desktop.
Ah, of course, you're right -- problem solved (wrongly :)
Agreed that it does not go well with multiversion.
Yeah, if all the previous kernels are really gone, it looks risky. Maybe we can drop Obsolete tag but only give Provides tag, supposing the multi-version allows it? Need to test...
It will certainly work for this use case. But it will not do the right thing during a zypper dup / offline update to a new release, where you expect the old packages to be removed. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 04 Sep 2015 11:30:03 +0200, Michal Marek wrote:
On 2015-09-04 11:21, Takashi Iwai wrote:
On Fri, 04 Sep 2015 11:13:54 +0200, Michal Marek wrote:
On 2015-09-04 11:11, Takashi Iwai wrote:
Now thinking of the KMP issues again: by obsoleting, the old desktop-kmp gets removed. Then this will break the previous kernel boot? Or, KMP isn't covered in anyway for multi-boot?
The kernel-default package will also obsolete kernel-desktop.
Ah, of course, you're right -- problem solved (wrongly :)
Agreed that it does not go well with multiversion.
Yeah, if all the previous kernels are really gone, it looks risky. Maybe we can drop Obsolete tag but only give Provides tag, supposing the multi-version allows it? Need to test...
It will certainly work for this use case. But it will not do the right thing during a zypper dup / offline update to a new release, where you expect the old packages to be removed.
Does zypper dup from an old release remove the old kernel? I didn't think of that. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-09-04 11:42, Takashi Iwai wrote:
On Fri, 04 Sep 2015 11:30:03 +0200, Michal Marek wrote:
On 2015-09-04 11:21, Takashi Iwai wrote:
On Fri, 04 Sep 2015 11:13:54 +0200, Michal Marek wrote:
On 2015-09-04 11:11, Takashi Iwai wrote:
Now thinking of the KMP issues again: by obsoleting, the old desktop-kmp gets removed. Then this will break the previous kernel boot? Or, KMP isn't covered in anyway for multi-boot?
The kernel-default package will also obsolete kernel-desktop.
Ah, of course, you're right -- problem solved (wrongly :)
Agreed that it does not go well with multiversion.
Yeah, if all the previous kernels are really gone, it looks risky. Maybe we can drop Obsolete tag but only give Provides tag, supposing the multi-version allows it? Need to test...
It will certainly work for this use case. But it will not do the right thing during a zypper dup / offline update to a new release, where you expect the old packages to be removed.
Does zypper dup from an old release remove the old kernel? I didn't think of that.
I'm not 100% sure about zypper dup, but an old-fashioned offline upgrade removes the old kernel. So adding Obsoletes: in case a kernel flavor is dropped is a good idea in such case. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-09-03 11:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus.
One reason to use the -default setting came to my mind -- if we use CONFIG_PREEMPT_NONE=y and CONFIG_HZ=250, a future Leap kernel will be binary compatible with a future SLES kernel, it will only differ in the SUSE_KERNEL_SUPPORTED setting. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2015-09-23 at 15:29 +0200, Michal Marek wrote:
On 2015-09-03 11:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
I don't see any reason to keep HZ=1000, there are oodles of preempt opportunities in a PREEMPT kernel.
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus.
One reason to use the -default setting came to my mind -- if we use CONFIG_PREEMPT_NONE=y and CONFIG_HZ=250, a future Leap kernel will be binary compatible with a future SLES kernel, it will only differ in the SUSE_KERNEL_SUPPORTED setting.
Down side of PREEMPT_NONE is higher scheduling latency across the board. Desktop users may feel the difference under load, may gripe, anybody watching realtime latencies will gripe. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-09-23 16:37, Mike Galbraith wrote:
On Wed, 2015-09-23 at 15:29 +0200, Michal Marek wrote:
On 2015-09-03 11:26, Michal Marek wrote:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
I don't see any reason to keep HZ=1000, there are oodles of preempt opportunities in a PREEMPT kernel.
So CONFIG_PREEMPT=y, CONFIG_HZ=250? Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2015-09-23 at 17:18 +0200, Michal Marek wrote:
On 2015-09-23 16:37, Mike Galbraith wrote:
On Wed, 2015-09-23 at 15:29 +0200, Michal Marek wrote:
On 2015-09-03 11:26, Michal Marek wrote:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
I don't see any reason to keep HZ=1000, there are oodles of preempt opportunities in a PREEMPT kernel.
So CONFIG_PREEMPT=y, CONFIG_HZ=250?
Yeah, I would say that's better for a primarily desktop audience. Most wouldn't notice, but anybody really needing low latency would. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Dne 23.9.2015 v 17:29 Mike Galbraith napsal(a):
On Wed, 2015-09-23 at 17:18 +0200, Michal Marek wrote:
On 2015-09-23 16:37, Mike Galbraith wrote:
On Wed, 2015-09-23 at 15:29 +0200, Michal Marek wrote:
On 2015-09-03 11:26, Michal Marek wrote:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
I don't see any reason to keep HZ=1000, there are oodles of preempt opportunities in a PREEMPT kernel.
So CONFIG_PREEMPT=y, CONFIG_HZ=250?
Yeah, I would say that's better for a primarily desktop audience. Most wouldn't notice, but anybody really needing low latency would.
I submitted such change for the master branch. Once accepted, I will prepare the same commit for stable and openSUSE-42.1. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am Mittwoch, 23. September 2015, 16:37:59 schrieb Mike Galbraith: Hi,
I don't see any reason to keep HZ=1000, there are oodles of preempt opportunities in a PREEMPT kernel.
Down side of PREEMPT_NONE is higher scheduling latency across the board. Desktop users may feel the difference under load, may gripe, anybody watching realtime latencies will gripe.
You will notice negative effects with many audio use cases and with other latency critical desktop hardware. Also simple stuff like desktop latency will worsen in case of I/O e.g.akonady,.... Any audio clitch will be annoying. Why should desktop people suffer these occassional clitches? Binary compatibility of kernel modules with SLES is no such big win. Regards --martin konold -- Dipl.-Physiker Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Registergericht: Amtsgericht Stuttgart PR 126 Firmensitz: Adolfstraße 23, 70469 Stuttgart fon: 0711 67400963 fax: 0711 67400959 email: martin.konold@erfrakon.de http://www.erfrakon.de -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2015-09-23 at 17:37 +0200, Martin Konold wrote:
Am Mittwoch, 23. September 2015, 16:37:59 schrieb Mike Galbraith:
Hi,
I don't see any reason to keep HZ=1000, there are oodles of preempt opportunities in a PREEMPT kernel.
Down side of PREEMPT_NONE is higher scheduling latency across the board. Desktop users may feel the difference under load, may gripe, anybody watching realtime latencies will gripe.
You will notice negative effects with many audio use cases and with other latency critical desktop hardware. Also simple stuff like desktop latency will worsen in case of I/O e.g.akonady,....
PREEMPT/NONE won't change much of anything if you beat hell outta a single speck of spinning rust. The cure for that is rust removal :)
Any audio clitch will be annoying.
I've never encountered an audio glitch in a desktop app that wasn't inadequate buffering since CFS was born. The old O(1) was a different beast, there, scheduling latency _could_ be up to and including infinity if you knew how to tickle it properly.
Why should desktop people suffer these occassional clitches?
Most users wouldn't notice a thing, because most of us rarely saturate our ever increasing CPU resources. But yeah, when you do saturate, you may notice. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am Mittwoch, 23. September 2015, 18:10:53 schrieben Sie: Hi,
Most users wouldn't notice a thing, because most of us rarely saturate our ever increasing CPU resources. But yeah, when you do saturate, you may notice.
This is a common misunderstanding. CONFIG_PREEMPT=y is for dealing with low latency requirements especially with still a significant number of linux drivers and subsystems optimized for throughput. Preemption is not about preventing nor dealing with CPU saturation. Actually in most cases where latency issues arise some cores are actually idleing but other subsystems are saturated. Regards --martin konold -- Dipl.-Physiker Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Registergericht: Amtsgericht Stuttgart PR 126 Firmensitz: Adolfstraße 23, 70469 Stuttgart fon: 0711 67400963 fax: 0711 67400959 email: martin.konold@erfrakon.de http://www.erfrakon.de -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2015-09-23 at 18:27 +0200, Martin Konold wrote:
Am Mittwoch, 23. September 2015, 18:10:53 schrieben Sie:
Hi,
Most users wouldn't notice a thing, because most of us rarely saturate our ever increasing CPU resources. But yeah, when you do saturate, you may notice.
This is a common misunderstanding.
CONFIG_PREEMPT=y is for dealing with low latency requirements especially with still a significant number of linux drivers and subsystems optimized for throughput.
Preemption is not about preventing nor dealing with CPU saturation.
Actually in most cases where latency issues arise some cores are actually idleing but other subsystems are saturated.
Bah, explain entanglement to me instead, that I do not understand :) -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
23.09.2015 16:29, Michal Marek пишет:
On 2015-09-03 11:26, Michal Marek wrote:
Hi,
since Leap is sharing code with SLE and it will eventually share the kernel as well, I would like to align the config/ directory with the SLE kernel where practical. ia64 has already been deleted, same happened to the trace flavors. We probably want to keep the 32bit ARM, PPC and x86 architectures, to make it easier to build Leap ports for those architectures. What we can drop is the -desktop flavor. Since openSUSE releases have been using this flavor by default, I assume that this is what the majority of users are running, so we probably want to keep some of the settings of the -desktop flavor, to make the transition seamless. Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
Basil noted that CONFIG_SCHED_AUTOGROUP is enabled in -desktop and disabled in -default. Is it intentional?
Left for discussion is whether PREEMPT and HZ=1000 are actually worth it even on desktop. The setting can be flipped back later if there is a consensus.
One reason to use the -default setting came to my mind -- if we use CONFIG_PREEMPT_NONE=y and CONFIG_HZ=250, a future Leap kernel will be binary compatible with a future SLES kernel, it will only differ in the SUSE_KERNEL_SUPPORTED setting.
Michal
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2015-10-21 07:32, Andrei Borzenkov wrote:
23.09.2015 16:29, Michal Marek пишет:
On 2015-09-03 11:26, Michal Marek wrote:
Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
Basil noted that CONFIG_SCHED_AUTOGROUP is enabled in -desktop and disabled in -default. Is it intentional?
It is, I just forgot to mention it in my email. To quote Mike Galbraith's post in an earlier internal discussion about this topic: "They bring lots of both benefit and pain. For instance, group scheduling (say autogroup) can markedly improve your desktop experience when there's a gaggle of CPU hungry tasks competing with your interactive apps. It's really good for _that_ scenario, but does nada for the #1 interactivity annoyance, namely IO. It also has a rude surprise for anyone who wants to run something nice 19 to reserve bandwidth for more important things, as nice level means nothing outside of any task group. Group scheduling always costs you cycles, but doesn't always produce a nice return for the investment." Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2015-10-21 at 10:20 +0200, Michal Marek wrote:
On 2015-10-21 07:32, Andrei Borzenkov wrote:
23.09.2015 16:29, Michal Marek пишет:
On 2015-09-03 11:26, Michal Marek wrote:
Therefore, I propose the following:
- Set CONFIG_PREEMPT=y, CONFIG_HZ=1000 in i386/pae and x86_64/default - Set the sysctl default vm.dirty_ratio=20 for these two flavors - Make i386/pae and x86_64/default obsolete kernel-desktop
So, does anybody oppose this plan? If not, I will push it to master and stable.
Basil noted that CONFIG_SCHED_AUTOGROUP is enabled in -desktop and disabled in -default. Is it intentional?
It is, I just forgot to mention it in my email. To quote Mike Galbraith's post in an earlier internal discussion about this topic:
"They bring lots of both benefit and pain.
For instance, group scheduling (say autogroup) can markedly improve your desktop experience when there's a gaggle of CPU hungry tasks competing with your interactive apps. It's really good for _that_ scenario, but does nada for the #1 interactivity annoyance, namely IO. It also has a rude surprise for anyone who wants to run something nice 19 to reserve bandwidth for more important things, as nice level means nothing outside of any task group. Group scheduling always costs you cycles, but doesn't always produce a nice return for the investment."
There is a down side to turning it off, in that those who were getting the upside, and weren't annoyed by the down side now get neither. I thought I saw a user@ service file while running TW, but perhaps not, rummaging around in 42.1, I don't see one (and user@0 is root), so seems there's now no canned group scheduling option, userspace or kernelspace. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2015-10-21 at 11:18 +0200, Mike Galbraith wrote:
I thought I saw a user@ service file while running TW, but perhaps not, rummaging around in 42.1, I don't see one (and user@0 is root), so seems there's now no canned group scheduling option, userspace or kernelspace.
BTW, the user@ service does exist, I just went temporarily blind. I tried to check it out, but it doesn't seem to want to do anything at all for a normal user. For root, it'll set up cgroups (whether you like it or not unless you mask the bloody thing), but everything lands in one bucket, so it's fairly useless. For those who routinely run hefty batch jobs, it's trivial to create cgroups and use cgexec to launch them, so no big deal. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (10)
-
Andrei Borzenkov -
Basil Chupin -
Bruno Friedmann -
Carlos E. R. -
Greg Freemyer -
Martin Konold -
Michal Marek -
Mike Galbraith -
Stefan Seyfried -
Takashi Iwai