[opensuse-kernel] Jump: merge Leap and SLE kernel configs
Hi kernel team and Jump team, Kernel configs are very different between Leap and SLE, at least for arm64/default. Few examples for arm64: * CONFIG_NO_HZ_IDLE vs CONFIG_NO_HZ_FULL * Preemption * OTG support missing in SLE * Various drivers (sensors, network, touchscreens, etc.) missing in SLE What is the plan regarding kernels? Do we merge the configs? Or do we rebuild the kernel for Jump? I know SLE has some features disabled on purpose, but Leap had some features enabled on purpose as well. Cheers, Guillaume IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 9/2/20 7:00 PM, Guillaume Gardet wrote:
Hi kernel team and Jump team,
Kernel configs are very different between Leap and SLE, at least for arm64/default. Few examples for arm64:
- CONFIG_NO_HZ_IDLE vs CONFIG_NO_HZ_FULL
- Preemption
- OTG support missing in SLE
- Various drivers (sensors, network, touchscreens, etc.) missing in SLE
What is the plan regarding kernels? Do we merge the configs? Or do we rebuild the kernel for Jump?
I know SLE has some features disabled on purpose, but Leap had some features enabled on purpose as well.
Cheers, Guillaume
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Guillaume we are working in sync :D I just saw the same for ppc64le as per https://bugzilla.opensuse.org/show_bug.cgi?id=1176090#c2 -- Michel Normand -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 02 Sep 2020 19:00:40 +0200, Guillaume Gardet wrote:
Hi kernel team and Jump team,
Kernel configs are very different between Leap and SLE, at least for arm64/default. Few examples for arm64:
- CONFIG_NO_HZ_IDLE vs CONFIG_NO_HZ_FULL
- Preemption
- OTG support missing in SLE
- Various drivers (sensors, network, touchscreens, etc.) missing in SLE
What is the plan regarding kernels? Do we merge the configs? Or do we rebuild the kernel for Jump?
I know SLE has some features disabled on purpose, but Leap had some features enabled on purpose as well.
Actually it's the topic we've been evaluating and discussing internally in last weeks. The current plan (or hope) is that we're going to unify the kconfigs. Most of the performance-related configs will be aligned with the SLE setup, while enabling the missing features on its top. e.g. about the preemption, we can follow the SLE pattern, namely, kernel-default = PREEMPT_NONE (typically server usage) and kernel-preempt = PREEMPT_FULL (typically desktop usage) instead of a single kernel flavor for all. How to package the newly enabled modules is still an open question. We may put into kernel-default-extra, or we may split another subpackage. Or we may fork another flavor dedicated for leap. In anyway, we hope that some solid proposals will be ready not too late, and submit to this ML for further discussions. BTW, this may be a good chance to drop really unused features, too. e.g. CONFIG_ISDN or CONFIG_PCMCIA came to my mind. So, in addition to those such obvious ones, if you can review the existing config and suggest some candidates to drop, it'd be greatly appreciated. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am Donnerstag, 3. September 2020, 19:14:56 CEST schrieb Takashi Iwai:
e.g. about the preemption, we can follow the SLE pattern, namely, kernel-default = PREEMPT_NONE (typically server usage) and kernel-preempt = PREEMPT_FULL (typically desktop usage) instead of a single kernel flavor for all.
Does that mean, we can expect another kernel flavor (-preempt) in Kernel:stable soon? This would be *much* appreciated, of course. Interestingly, since 5.8.x (from Kernel:stable) is driving my desktop (i7-4790K/32GB Ram), I experience small scheduler related regressions sometimes: eg. no screen updates for a couple of seconds, if I build some package. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, Sep 04, 2020 at 01:35:43PM +0200, Hans-Peter Jansen wrote:
Am Donnerstag, 3. September 2020, 19:14:56 CEST schrieb Takashi Iwai:
e.g. about the preemption, we can follow the SLE pattern, namely, kernel-default = PREEMPT_NONE (typically server usage) and kernel-preempt = PREEMPT_FULL (typically desktop usage) instead of a single kernel flavor for all.
Does that mean, we can expect another kernel flavor (-preempt) in Kernel:stable soon? This would be *much* appreciated, of course.
Not directly as this is about Leap where we already have preempt flavor (even if only for x86_64 and aarch64) and the only difference is that kernel-default has PREEMPT_VOLUNTARY on Leap and PREEMPT_NONE on SLE. So the only question is if we switch Leap kernel-default to PREEMPT_NONE in openSUSE-15.3 to match SLE15-SP3. On the other hand, having two flavors also in Tumbleweed would IMHO make sense but I would suggest to wait until we decide what settings we use in 15.3 and do the same in Tumbleweed then. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 2020-09-04 at 14:25 +0200, Michal Kubecek wrote:
On Fri, Sep 04, 2020 at 01:35:43PM +0200, Hans-Peter Jansen wrote:
Am Donnerstag, 3. September 2020, 19:14:56 CEST schrieb Takashi Iwai:
e.g. about the preemption, we can follow the SLE pattern, namely, kernel-default = PREEMPT_NONE (typically server usage) and kernel-preempt = PREEMPT_FULL (typically desktop usage) instead of a single kernel flavor for all.
Does that mean, we can expect another kernel flavor (-preempt) in Kernel:stable soon? This would be *much* appreciated, of course.
Not directly as this is about Leap where we already have preempt flavor (even if only for x86_64 and aarch64) and the only difference is that kernel-default has PREEMPT_VOLUNTARY on Leap and PREEMPT_NONE on SLE. So the only question is if we switch Leap kernel-default to PREEMPT_NONE in openSUSE-15.3 to match SLE15-SP3.
Yep, and perhaps switch kernel-preempt to PREEMPT_FULL as, for desktops, that's probably the best config... Or maybe add even another one, i.e., kernel-default = PREEMPT_NONE, kernel-preempt = PREEMPT_VOLUNTARY, kernel-desktop = PREEMPT_FULL and finally kernel-rt! :-P
On the other hand, having two flavors also in Tumbleweed would IMHO make sense
Yep, very much! FWIW, I follow a few user's forums, chats and groups, and not only openSUSE ones, and this a feature that users tend to like quite a bit, in the distros that have it.
but I would suggest to wait until we decide what settings we use in 15.3 and do the same in Tumbleweed then.
Seems to make a lot sense indeed. :-) Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
Am Freitag, 4. September 2020, 14:25:57 CEST schrieb Michal Kubecek:
On Fri, Sep 04, 2020 at 01:35:43PM +0200, Hans-Peter Jansen wrote:
Am Donnerstag, 3. September 2020, 19:14:56 CEST schrieb Takashi Iwai:
e.g. about the preemption, we can follow the SLE pattern, namely,
kernel-default = PREEMPT_NONE (typically server usage) and kernel-preempt = PREEMPT_FULL (typically desktop usage)
instead of a single kernel flavor for all.
Does that mean, we can expect another kernel flavor (-preempt) in Kernel:stable soon? This would be *much* appreciated, of course.
Not directly as this is about Leap where we already have preempt flavor (even if only for x86_64 and aarch64) and the only difference is that kernel-default has PREEMPT_VOLUNTARY on Leap and PREEMPT_NONE on SLE. So the only question is if we switch Leap kernel-default to PREEMPT_NONE in openSUSE-15.3 to match SLE15-SP3.
On the other hand, having two flavors also in Tumbleweed would IMHO make sense but I would suggest to wait until we decide what settings we use in 15.3 and do the same in Tumbleweed then.
Well, for the impatient like me, a preempt build of Kernel:stable for TW is available: https://build.opensuse.org/project/monitor/home:frispete:kernel Be careful, if you depend on special custom kernel modules (eg. nvidia), those need to be added to the repo or created manually (or send a PM). Note, that I don't adhere to the correct workflow for openSUSE kernels ATM. But it should be good enough for experimenting. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2020/09/03 10:14, Takashi Iwai wrote:
Actually it's the topic we've been evaluating and discussing internally in last weeks.
The current plan (or hope) is that we're going to unify the kconfigs. Most of the performance-related configs will be aligned with the SLE setup, while enabling the missing features on its top.
e.g. about the preemption, we can follow the SLE pattern, namely, kernel-default = PREEMPT_NONE (typically server usage) and kernel-preempt = PREEMPT_FULL (typically desktop usage) instead of a single kernel flavor for all.
---- What is the single flavor now? What flavor would you use on a server that serves files (I would not think that an uncommon usage for a server). I use my server to serv ALL of my files except programs. Looking through my videos, the most demanding I have now at 1080p with DTS HD 5.1 w/ multiaudio, needs 38Mbps. It is an 8-bit encoding I'd say that works comfortably with a PREEMPT_VOLUNTARY, however, about 7-10 years ago, **PREEMPT_NONE** **failed** **frequently**, even with the much less demanding streams available then. Of note -- I'm not sure how this interacts with the above, though I run a tickless clock, it still wants a clock Hz which I have set at 1000Hz. I don't have any of the newer 4K vids which would need about 4X the BW, not to mention the 8K video that Nvidia was just demoing with their latest 3xxx series cards. Additionally many newer videos have 10-12 bit color with 48-bits of color -- I'd expect that to go to 16bit within the next few-several years as a round-up of the 14bit range for the human eye. I really don't think the NONE config is going to be useful for most server configs unless they are pure "batch"-job machines with no interactive or user dependencies. As for PREEMPT_FULL -- I'm sure some scientific, maybe even gaming platform boxes might find a use for that -- but I'd tend to think PREEMPT_VOLUNTARY would work for most people in most cases. - -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 07 Sep 2020 00:49:49 +0200, L A Walsh wrote:
On 2020/09/03 10:14, Takashi Iwai wrote:
Actually it's the topic we've been evaluating and discussing internally in last weeks.
The current plan (or hope) is that we're going to unify the kconfigs. Most of the performance-related configs will be aligned with the SLE setup, while enabling the missing features on its top.
e.g. about the preemption, we can follow the SLE pattern, namely, kernel-default = PREEMPT_NONE (typically server usage) and kernel-preempt = PREEMPT_FULL (typically desktop usage) instead of a single kernel flavor for all.
What is the single flavor now?
kernel-default with PREEMPT_VOLUNTARY.
What flavor would you use on a server that serves files (I would not think that an uncommon usage for a server). I use my server to serv ALL of my files except programs. Looking through my videos, the most demanding I have now at 1080p with DTS HD 5.1 w/ multiaudio, needs 38Mbps. It is an 8-bit encoding I'd say that works comfortably with a PREEMPT_VOLUNTARY, however, about 7-10 years ago, **PREEMPT_NONE** **failed** **frequently**, even with the much less demanding streams available then. Of note -- I'm not sure how this interacts with the above, though I run a tickless clock, it still wants a clock Hz which I have set at 1000Hz.
If PREEMPT_NONE gave the lower throughput for a pure server task (i.e. not watching video on that machine or doing interactive tasks there), something must have been broken there and it should have been fixed.
I don't have any of the newer 4K vids which would need about 4X the BW, not to mention the 8K video that Nvidia was just demoing with their latest 3xxx series cards. Additionally many newer videos have 10-12 bit color with 48-bits of color -- I'd expect that to go to 16bit within the next few-several years as a round-up of the 14bit range for the human eye.
I really don't think the NONE config is going to be useful for most server configs unless they are pure "batch"-job machines with no interactive or user dependencies.
PREEMPT_VOLUNTARY has actually a significant negative performance impact wrt throughput measured by the benchmarks. That's the very reason SLE uses this option for kernel-default.
As for PREEMPT_FULL -- I'm sure some scientific, maybe even gaming platform boxes might find a use for that -- but I'd tend to think PREEMPT_VOLUNTARY would work for most people in most cases.
If you have only one choice, yes. But you'll have two choices, then the situation changes pretty much. Again, if anything goes wrong with PREEMPT_NONE for the typical server usage, it must be fixed. PREEMPT_VOLUNTARY is not meant as a solution for such a problem. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 9/6/2020 11:52 PM, Takashi Iwai wrote:
If PREEMPT_NONE gave the lower throughput for a pure server task (i.e. not watching video on that machine or doing interactive tasks there), something must have been broken there and it should have been fixed.
I think you misunderstand. What is probably the most common thing a server does? My guess would be that it serves disk space. It's not that someone is watching video ON the MACHINE, but that multi-media content is likely to be *stored* or *hosted* on the server. That and web-pages, dns-lookups for example. What does a server do, in your view? In my view it "serves". It does tasks for users who wouldn't have media or web-sites on the machine. Ideally dns-lookups will take <10ms. If you load a busy webpage, it can easily have 20-30 DNS lookups or more. Hopefully most would be in cache for commonly view sites -- but I've noticed alot of short-timeout DNS values that keep that content from being cached for long periods of time. But the main place I'd see non-preempt making a difference was in large video streams hosted on the server (not being watched on the server).
PREEMPT_VOLUNTARY has actually a significant negative performance impact wrt throughput measured by the benchmarks. That's the very reason SLE uses this option for kernel-default.
--- I'm sure it depends on your workload. If you are doing pure batch and really not doing "server" tasks (serving resources to a user), and just computing...I can see PREEMPT_NONE being best. What type of workloads are you using for servers -- ones that serve multiple users doing interactive tasks or ones that are mostly compute-bound doing long and large running jobs?
Again, if anything goes wrong with PREEMPT_NONE for the typical server usage, it must be fixed. PREEMPT_VOLUNTARY is not meant as a solution for such a problem.
--- It may be down to definitions and how you define a server and its workload. A server performing the functions of serving several or many interactive users needs more interactivity than compute or long-running data-processing jobs. Perhaps using VOLUNTARY, but reserve some servers for compute tasks that won't service user requests. Specifically using the "isolcpus=" boot param to isolate some of the cpu's from "interruption noise" -- specifically the kernel configurator says: CONFIG_CPU_ISOLATION: Make sure that CPUs running critical tasks are not disturbed by any source of "noise" such as unbound workqueues, timers, kthreads... Unbound jobs get offloaded to housekeeping CPUs. This is driven by the "isolcpus=" boot parameter. Perhaps reserving half for critical tasks so they are not disturbed and the remainder for interactive serving might serve the purpose. It sounds like not having compute-jobs interrupted is a key requirement of what you are looking for? In 'xconfig', it's right below the Preemption model and has the benefit of being configurable per machine. Do you have any links to the impact on throughput of the Preemption Model? Vs. effects of cpu isolation and/or changes to the timeslice values? Odd -- I thought there was better support for changing timeslice values, but all I see seems to have to do with a graphics chip (DRM_I915_TIMESLICE_DURATION). Must be confusing it with the NT kernel knobs for such. Do you know of a test case that fails using PREEMPT VOLUNTARY vs. NONE or where it's seen that one performs significantly better under some workload? How typical is the workload? Note: PREEMPT NONE is for kernels used for scientific computation that needs the raw processing power of the kernel, regardless of scheduling latencies. I'm not doing such work straight computing, but instead use the server, mostly, for serving incoming network requests. Depending on packet and request size, One(1) 10Gb connection can saturate a single cpu. Supposedly RedHat disabled various C-States if you use 9K network packets, as long latencies imposed by deeper power saving states can theoretically cause some packet loss. If the cpu is not preemptable, wouldn't the same situation exist? Conversely I see some disable Jumbo packets, which, when compared to standard, causes network throughput drop from 400-600MB/s down to 110MB/s. That's unacceptable for servers serving internal network requests. How much does 'Preempt none' benefit what workload over voluntary? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 10 Sep 2020 01:47:53 +0200, L A Walsh wrote:
On 9/6/2020 11:52 PM, Takashi Iwai wrote:
If PREEMPT_NONE gave the lower throughput for a pure server task (i.e. not watching video on that machine or doing interactive tasks there), something must have been broken there and it should have been fixed.
I think you misunderstand.
What is probably the most common thing a server does? My guess would be that it serves disk space.
It's not that someone is watching video ON the MACHINE, but that multi-media content is likely to be *stored* or *hosted* on the server. That and web-pages, dns-lookups for example.
What does a server do, in your view? In my view it "serves". It does tasks for users who wouldn't have media or web-sites on the machine. Ideally dns-lookups will take <10ms. If you load a busy webpage, it can easily have 20-30 DNS lookups or more. Hopefully most would be in cache for commonly view sites -- but I've noticed alot of short-timeout DNS values that keep that content from being cached for long periods of time.
But the main place I'd see non-preempt making a difference was in large video streams hosted on the server (not being watched on the server).
Well, that's of course a typical use case of servers, and I understand it well, too. The point is that PREEMPT_NONE was from SLE *Server* product, and that's the business SUSE has been doing over decades, and the config was chosen by the evaluation of various benchmarks and QAs to cover this kind of use cases. If you have really a performance problem with the setup and work with PREEMPT_VOLUNTARY, it should be fixed; PREEMPT_VOLUNTARY isn't meant as a solution from the beginning of its introduction. That's a difference from a full RT.
PREEMPT_VOLUNTARY has actually a significant negative performance impact wrt throughput measured by the benchmarks. That's the very reason SLE uses this option for kernel-default.
I'm sure it depends on your workload. If you are doing pure batch and really not doing "server" tasks (serving resources to a user), and just computing...I can see PREEMPT_NONE being best.
What type of workloads are you using for servers -- ones that serve multiple users doing interactive tasks or ones that are mostly compute-bound doing long and large running jobs?
Again, if anything goes wrong with PREEMPT_NONE for the typical server usage, it must be fixed. PREEMPT_VOLUNTARY is not meant as a solution for such a problem.
It may be down to definitions and how you define a server and its workload. A server performing the functions of serving several or many interactive users needs more interactivity than compute or long-running data-processing jobs.
Perhaps using VOLUNTARY, but reserve some servers for compute tasks that won't service user requests.
Specifically using the "isolcpus=" boot param to isolate some of the cpu's from "interruption noise" -- specifically the kernel configurator says:
CONFIG_CPU_ISOLATION:
Make sure that CPUs running critical tasks are not disturbed by any source of "noise" such as unbound workqueues, timers, kthreads... Unbound jobs get offloaded to housekeeping CPUs. This is driven by the "isolcpus=" boot parameter.
Perhaps reserving half for critical tasks so they are not disturbed and the remainder for interactive serving might serve the purpose.
It sounds like not having compute-jobs interrupted is a key requirement of what you are looking for? In 'xconfig', it's right below the Preemption model and has the benefit of being configurable per machine.
Do you have any links to the impact on throughput of the Preemption Model? Vs. effects of cpu isolation and/or changes to the timeslice values?
Odd -- I thought there was better support for changing timeslice values, but all I see seems to have to do with a graphics chip (DRM_I915_TIMESLICE_DURATION). Must be confusing it with the NT kernel knobs for such.
Do you know of a test case that fails using PREEMPT VOLUNTARY vs. NONE or where it's seen that one performs significantly better under some workload? How typical is the workload?
Note: PREEMPT NONE is for kernels used for scientific computation that needs the raw processing power of the kernel, regardless of scheduling latencies. I'm not doing such work straight computing, but instead use the server, mostly, for serving incoming network requests. Depending on packet and request size, One(1) 10Gb connection can saturate a single cpu.
Supposedly RedHat disabled various C-States if you use 9K network packets, as long latencies imposed by deeper power saving states can theoretically cause some packet loss. If the cpu is not preemptable, wouldn't the same situation exist? Conversely I see some disable Jumbo packets, which, when compared to standard, causes network throughput drop from 400-600MB/s down to 110MB/s. That's unacceptable for servers serving internal network requests.
How much does 'Preempt none' benefit what workload over voluntary?
This can be answered best by the performance team, who has been carrying the tests and evaluations. And I'm off from today, so any further reply will be delayed. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu 10-09-20 07:59:13, Takashi Iwai wrote:
Do you know of a test case that fails using PREEMPT VOLUNTARY vs. NONE or where it's seen that one performs significantly better under some workload? How typical is the workload?
Note: PREEMPT NONE is for kernels used for scientific computation that needs the raw processing power of the kernel, regardless of scheduling latencies. I'm not doing such work straight computing, but instead use the server, mostly, for serving incoming network requests. Depending on packet and request size, One(1) 10Gb connection can saturate a single cpu.
Supposedly RedHat disabled various C-States if you use 9K network packets, as long latencies imposed by deeper power saving states can theoretically cause some packet loss. If the cpu is not preemptable, wouldn't the same situation exist? Conversely I see some disable Jumbo packets, which, when compared to standard, causes network throughput drop from 400-600MB/s down to 110MB/s. That's unacceptable for servers serving internal network requests.
How much does 'Preempt none' benefit what workload over voluntary?
This can be answered best by the performance team, who has been carrying the tests and evaluations.
I believe Mel did some comparisons for this in the past. Mel? Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am Mittwoch, 16. September 2020, 15:15:55 CEST schrieb Jan Kara:
On Thu 10-09-20 07:59:13, Takashi Iwai wrote:
Do you know of a test case that fails using PREEMPT
VOLUNTARY vs. NONE or where it's seen that one performs significantly better under some workload? How typical is the workload?
Note: PREEMPT NONE is for kernels used for scientific computation
that needs the raw processing power of the kernel, regardless of scheduling latencies. I'm not doing such work straight computing, but instead use the server, mostly, for serving incoming network requests. Depending on packet and request size, One(1) 10Gb connection can saturate a single cpu.
Supposedly RedHat disabled various C-States if you use 9K network packets, as long latencies imposed by deeper power saving states can theoretically cause some packet loss. If the cpu is not preemptable, wouldn't the same situation exist? Conversely I see some disable Jumbo packets, which, when compared to standard, causes network throughput drop from 400-600MB/s down to 110MB/s. That's unacceptable for servers serving internal network requests.
How much does 'Preempt none' benefit what workload over voluntary?
This can be answered best by the performance team, who has been carrying the tests and evaluations.
I believe Mel did some comparisons for this in the past. Mel?
As noted in the other leg of this thread, apart from PREEMPT_NONE, the NO_HZ_FULL vs. NO_HZ_IDLE should be included into this discussion. Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2020-09-09 at 16:47 -0700, L A Walsh wrote:
On 9/6/2020 11:52 PM, Takashi Iwai wrote: Do you have any links to the impact on throughput of the Preemption Model? Vs. effects of cpu isolation and/or changes to the timeslice values?
Odd -- I thought there was better support for changing timeslice values, but all I see seems to have to do with a graphics chip (DRM_I915_TIMESLICE_DURATION). Must be confusing it with the NT kernel knobs for such.
Timeslice is, let's say, dynamic in CFS. And controlled by nice levels. Perhaps what you're looking for is HZ (CONFIG_HZ) ? And perhaps hrtick, but that comes later. :-) Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
participants (8)
-
Dario Faggioli -
Guillaume Gardet -
Hans-Peter Jansen -
Jan Kara -
L A Walsh -
Michal Kubecek -
Normand -
Takashi Iwai