Request for low latency kernel CONFIG_HZ at 1000 Hz
I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there? My use case is very special: my environment is dealing with high speed cameras and the low frequency is needed to be able to manage high frame speed at several thousand frames per second. Right now I am using a special desktop kernel from a foreign source however I am wondering if there is any chance to have this into mainline LEAP distro available? I know my use case is very special and I should be able to maintain my own kernel for this, however I am wondering if this would be a nice benefit of the LEAP distribution in general and why the preempt kernel is kept at lower frequency still... Thanks Thomas
On 6/3/21 11:37 AM, Thomas Hartwig wrote:
I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there?
Primarily for historical reasons; 250 Hz was found to be a good compromise between interactive and non-interactive tasks.
My use case is very special: my environment is dealing with high speed cameras and the low frequency is needed to be able to manage high frame speed at several thousand frames per second. Right now I am using a special desktop kernel from a foreign source however I am wondering if there is any chance to have this into mainline LEAP distro available? I know my use case is very special and I should be able to maintain my own kernel for this, however I am wondering if this would be a nice benefit of the LEAP distribution in general and why the preempt kernel is kept at lower frequency still...
Actually this sounds like a case for the realtime kernel. If you have hardware with specific timing needs I would have thought that the driver/application/what have you should be moved to employing a 'realtime' scheduling policy, and manage the frame capture from within the driver rather than relying on the kernel interrupt timer to do it for you. If you had a need for raising the interrupt timer it really sounds like a bad driver design to me ... If, OTOH, you can convert your application to leveraging realtime priority you can look a the -rt kernel, which is geared up for precisely such usecases. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions Germany GmbH, 90409 Nürnberg GF: F. Imendörffer, HRB 36809 (AG Nürnberg)
Hi, first of all thanks for picking up this topic. I am an application level developer without being able to go into driver specific development. The driver is vendor provided so there is no chance for me to change its conceptional design. However all I can say is that the Interrupt Timer has influence on the driver performance and that I have good experience with non real time kernels as long as these have the higher frequency enabled. So the need of changing a driver is low, hence its design might be not optimal needing 1000 MHz tick timer but this is too long to discus here... I am wondering about the implications of using a real time kernel and its drawbacks, unfortunately the documentation about the differences and technical reasoning of different kernel layouts in the standard distribution is nearly nonexistent in OpenSuse, but I understand it is probably out of scope of unpaid services. BR Thomas On 6/7/21 11:59 AM, Hannes Reinecke wrote:
On 6/3/21 11:37 AM, Thomas Hartwig wrote:
I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there?
Primarily for historical reasons; 250 Hz was found to be a good compromise between interactive and non-interactive tasks.
My use case is very special: my environment is dealing with high speed cameras and the low frequency is needed to be able to manage high frame speed at several thousand frames per second. Right now I am using a special desktop kernel from a foreign source however I am wondering if there is any chance to have this into mainline LEAP distro available? I know my use case is very special and I should be able to maintain my own kernel for this, however I am wondering if this would be a nice benefit of the LEAP distribution in general and why the preempt kernel is kept at lower frequency still...
Actually this sounds like a case for the realtime kernel. If you have hardware with specific timing needs I would have thought that the driver/application/what have you should be moved to employing a 'realtime' scheduling policy, and manage the frame capture from within the driver rather than relying on the kernel interrupt timer to do it for you.
If you had a need for raising the interrupt timer it really sounds like a bad driver design to me ...
If, OTOH, you can convert your application to leveraging realtime priority you can look a the -rt kernel, which is geared up for precisely such usecases.
Cheers,
Hannes
On Mon, 07 Jun 2021 11:59:20 +0200, Hannes Reinecke wrote:
On 6/3/21 11:37 AM, Thomas Hartwig wrote:
I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there?
Primarily for historical reasons; 250 Hz was found to be a good compromise between interactive and non-interactive tasks.
My use case is very special: my environment is dealing with high speed cameras and the low frequency is needed to be able to manage high frame speed at several thousand frames per second. Right now I am using a special desktop kernel from a foreign source however I am wondering if there is any chance to have this into mainline LEAP distro available? I know my use case is very special and I should be able to maintain my own kernel for this, however I am wondering if this would be a nice benefit of the LEAP distribution in general and why the preempt kernel is kept at lower frequency still...
Actually this sounds like a case for the realtime kernel. If you have hardware with specific timing needs I would have thought that the driver/application/what have you should be moved to employing a 'realtime' scheduling policy, and manage the frame capture from within the driver rather than relying on the kernel interrupt timer to do it for you.
If you had a need for raising the interrupt timer it really sounds like a bad driver design to me ...
If, OTOH, you can convert your application to leveraging realtime priority you can look a the -rt kernel, which is geared up for precisely such usecases.
Well, if HZ=1000 really helps, it implies that it's no requirement of the hard RT, and kernel-preempt flavor would work enough for that purpose. AFAIK, kernel-preempt is available for Leap. And for TW, we're going to switch to the dynamic preempt, i.e. the preemption model is chosen via boot option. Takashi
Hi, for some reason PREEMPT is configured for 250? Am I missing something or is it by error? $: grep CONFIG_HZ /boot/config-5.3.18-lp152.75-preempt # CONFIG_HZ_PERIODIC is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 Thomas On 6/7/21 3:00 PM, Takashi Iwai wrote:
Well, if HZ=1000 really helps, it implies that it's no requirement of the hard RT, and kernel-preempt flavor would work enough for that purpose.
AFAIK, kernel-preempt is available for Leap. And for TW, we're going to switch to the dynamic preempt, i.e. the preemption model is chosen via boot option.
Takashi
On Mon, 07 Jun 2021 15:54:31 +0200, Thomas Hartwig wrote:
Hi,
for some reason PREEMPT is configured for 250? Am I missing something or is it by error?
$: grep CONFIG_HZ /boot/config-5.3.18-lp152.75-preempt # CONFIG_HZ_PERIODIC is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250
Basically HZ plays little role when the full preempt is enabled. Have you tested with kernel-preempt flavor as is? Give it a try once, if not done yet. If it still doesn't suffice, you can try the RT kernel like kernel-rt in OBS Kernel:SLE15-SP3-RT repo, too. Takashi
Thomas
On 6/7/21 3:00 PM, Takashi Iwai wrote:
Well, if HZ=1000 really helps, it implies that it's no requirement of the hard RT, and kernel-preempt flavor would work enough for that purpose.
AFAIK, kernel-preempt is available for Leap. And for TW, we're going to switch to the dynamic preempt, i.e. the preemption model is chosen via boot option.
Takashi
Hi Takashi, I tried preempt already without success, it is working but not fully satisfactory. Real-Time did crash the system for unknown reason yet, this is why I asked for detailed specs about Real-Time differences, however the Real-Time kernel really sound overwhelming as long as I only need the Interrupt timer being faster. BR Thomas On 6/7/21 4:37 PM, Takashi Iwai wrote:
On Mon, 07 Jun 2021 15:54:31 +0200, Thomas Hartwig wrote:
Hi,
for some reason PREEMPT is configured for 250? Am I missing something or is it by error?
$: grep CONFIG_HZ /boot/config-5.3.18-lp152.75-preempt # CONFIG_HZ_PERIODIC is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250
Basically HZ plays little role when the full preempt is enabled. Have you tested with kernel-preempt flavor as is? Give it a try once, if not done yet.
If it still doesn't suffice, you can try the RT kernel like kernel-rt in OBS Kernel:SLE15-SP3-RT repo, too.
Takashi
Thomas
On 6/7/21 3:00 PM, Takashi Iwai wrote:
Well, if HZ=1000 really helps, it implies that it's no requirement of the hard RT, and kernel-preempt flavor would work enough for that purpose.
AFAIK, kernel-preempt is available for Leap. And for TW, we're going to switch to the dynamic preempt, i.e. the preemption model is chosen via boot option.
Takashi
On Wed, 09 Jun 2021 12:52:18 +0200, Thomas Hartwig wrote:
Hi Takashi,
I tried preempt already without success, it is working but not fully satisfactory.
Hm, and yet CONFIG_HZ=1000 works? Then something odd there, and this has to be identified before diving into the blind increase of HZ. Otherwise it's a cargo-science. Takashi
Real-Time did crash the system for unknown reason yet, this is why I asked for detailed specs about Real-Time differences, however the Real-Time kernel really sound overwhelming as long as I only need the Interrupt timer being faster.
BR Thomas
On 6/7/21 4:37 PM, Takashi Iwai wrote:
On Mon, 07 Jun 2021 15:54:31 +0200, Thomas Hartwig wrote:
Hi,
for some reason PREEMPT is configured for 250? Am I missing something or is it by error?
$: grep CONFIG_HZ /boot/config-5.3.18-lp152.75-preempt # CONFIG_HZ_PERIODIC is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250
Basically HZ plays little role when the full preempt is enabled. Have you tested with kernel-preempt flavor as is? Give it a try once, if not done yet.
If it still doesn't suffice, you can try the RT kernel like kernel-rt in OBS Kernel:SLE15-SP3-RT repo, too.
Takashi
Thomas
On 6/7/21 3:00 PM, Takashi Iwai wrote:
Well, if HZ=1000 really helps, it implies that it's no requirement of the hard RT, and kernel-preempt flavor would work enough for that purpose.
AFAIK, kernel-preempt is available for Leap. And for TW, we're going to switch to the dynamic preempt, i.e. the preemption model is chosen via boot option.
Takashi
I will try to push it towards rocket science and come back later... On 6/9/21 1:04 PM, Takashi Iwai wrote:
On Wed, 09 Jun 2021 12:52:18 +0200, Thomas Hartwig wrote:
Hi Takashi,
I tried preempt already without success, it is working but not fully satisfactory.
Hm, and yet CONFIG_HZ=1000 works? Then something odd there, and this has to be identified before diving into the blind increase of HZ. Otherwise it's a cargo-science.
Takashi
On 2021/06/07 06:54, Thomas Hartwig wrote:
Hi,
for some reason PREEMPT is configured for 250? Am I missing something or is it by error?
$: grep CONFIG_HZ /boot/config-5.3.18-lp152.75-preempt # CONFIG_HZ_PERIODIC is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250
----- # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set && # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y --- Have always leaned toward 1kHz, it divides a bunch of ways. I went with the voluntary preempt, thought max latency in no preempt might make some things shudder, while my linux box really is more akin to a server and thought voluntary preemption might be sufficient. Haven't ever noticed downsides. Ya know, Opensuse does ship their src packages for kernels, you could always build a kernel from one of those. I like the idea of knowing what's in my kernel. I have a script to pull down latest patches from kernel.org for latest stable and I build from those patches/deltas Saves about 80% in disk space with the # kernel sources I keep around. I'd have to say building a kernel is one of the easier jobs you could try. Once you've got a build for your machine, you could even go for booting directly from disk...but takes a bit of bravery. But still if you use a currently running kernel as base sample of what drivers need to be included, its not that difficult to do.
Thomas
On 6/7/21 3:00 PM, Takashi Iwai wrote:
Well, if HZ=1000 really helps, it implies that it's no requirement of the hard RT, and kernel-preempt flavor would work enough for that purpose.
AFAIK, kernel-preempt is available for Leap. And for TW, we're going to switch to the dynamic preempt, i.e. the preemption model is chosen via boot option.
Takashi
Hi Walsh, thanks for sharing your experience. I am aware compiling kernels nowadays as probably quite easy, however when it comes to packaging and maintainability together with depend packages it becomes cumbersome. I need this kernel rather for productive systems and would like to have this simplified as best as possible at different ends. So my request is really serious in regards to this special feature in this kernel and I am wondering why this is not available at all? Thanks Thomas On 6/9/21 8:18 AM, L A Walsh wrote:
On 2021/06/07 06:54, Thomas Hartwig wrote:
Hi,
for some reason PREEMPT is configured for 250? Am I missing something or is it by error?
$: grep CONFIG_HZ /boot/config-5.3.18-lp152.75-preempt # CONFIG_HZ_PERIODIC is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250
# CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set && # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y
--- Have always leaned toward 1kHz, it divides a bunch of ways. I went with the voluntary preempt, thought max latency in no preempt might make some things shudder, while my linux box really is more akin to a server and thought voluntary preemption might be sufficient. Haven't ever noticed downsides.
Ya know, Opensuse does ship their src packages for kernels, you could always build a kernel from one of those. I like the idea of knowing what's in my kernel. I have a script to pull down latest patches from kernel.org for latest stable and I build from those patches/deltas Saves about 80% in disk space with the # kernel sources I keep around. I'd have to say building a kernel is one of the easier jobs you could try. Once you've got a build for your machine, you could even go for booting directly from disk...but takes a bit of bravery. But still if you use a currently running kernel as base sample of what drivers need to be included, its not that difficult to do.
Thomas
On 6/7/21 3:00 PM, Takashi Iwai wrote:
Well, if HZ=1000 really helps, it implies that it's no requirement of the hard RT, and kernel-preempt flavor would work enough for that purpose.
AFAIK, kernel-preempt is available for Leap. And for TW, we're going to switch to the dynamic preempt, i.e. the preemption model is chosen via boot option.
Takashi
Am Montag, 7. Juni 2021, 11:59:20 CEST schrieb Hannes Reinecke:
On 6/3/21 11:37 AM, Thomas Hartwig wrote:
I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there?
Thomas, I do build some special kernels in this regard here: https://build.opensuse.org/project/monitor/home:frispete:kernel The preempt flavor is using CONFIG_HZ_1000 (of course). For now, I build this kernel for TW only (target: openSUSE_Tumbleweed_Kernel_stable). It should work with Leap as well, but I can add other targets on request. To be honest, I build the kernels for my openSUSE zoo in an internal build service (for other reasons). The kernel is based on https://github.com/openSUSE/kernel-source/commits/stable With 2 scheduler changes *rebased*: https://github.com/frispete/kernel-source/tree/stable https://github.com/frispete/kernel-source/commit/ eff66ed807d15a93ee71e192ba1ed7394dd5e917 https://github.com/frispete/kernel-source/commit/ 1affceb6384e74af3027599a17113a5fe04fd835 I would be honored, if you could give this build a try. Please note, that these kernels are signed with my build key, which might trick UEFI into complaints and forcing you to add another certificate. As you can see, I try to stick to the "official" workflow, which makes dealing with such changes a breeze.
Primarily for historical reasons; 250 Hz was found to be a good compromise between interactive and non-interactive tasks.
Sure Hannes, but with the advent of preempt, there's a new opportunity to split this compromise into: default: voluntary preempt, optimized for non-interactive tasks, maximum throughput and efficiency preempt: full preempt, optimized for low latency, less maximum performance in favor of optimal interactivity At least in my modest tests, the preempt variant with HZ=1000 provides a better user experience on busy desktops *and* crowded servers. Probably HZ=1000 is a red herring here, but even my poor Gen-1 X1 Carbon runs happily with my preempt kernels without visible adverse effects in battery endurance (which is pretty limited in this edition anyway). At least, it beats a calm Win10 desktop easily.. Of course, this doesn't replace a wider investigation, but we should try to make the most of the possibilities of two different versions. I would like to see the preempt variant to use advanced CPU and compiler optimization techniques as well, but didn't dived into this yet. What could be achieved can be seen here: https://www.phoronix.com/scan.php?page=article&item=spring-2020-distros&num=1 We should take a leaf out of the Clear Linux* Project's book. Best, Pete
Hi Pete, thank you very much for the information and your work, I tested the preempt kernel 5.12 and it is performing very well. I think I can use these in production environments as well. This is good. It would be nice to have some for distribution releases 15.2/15.3 but as long as the repository is isolated for the kernels only I can use the Tumbleweed version for sure. Meanwhile I want to give some more technical background to the issues monitored. Please note I am not a kernel developer nor an expert. Instead I am an application developer with extended system knowledge and sometimes vertical hardware diving but mainly I am locked to application development, this is why I am limited in time and know-how what is going on specific kernel versions. The systems I work with are specialized video capturing systems working with industrial high speed cameras based on GigE (Basler/Pylon software driver). All this is TCP/IP stack based, so IMHO this is the most critical section. The systems are storing video frames in memory and these are further processed in complex multi-threaded applications. Simply to give some numbers here which are really impressive what a Linux system is capable of: 6 cameras are streaming at 4000 frames per second each with a bandwidth of 100 MB/s which is handled by a fiber optic network card X710. So roughly 600 MB/s are handled. The CPU is an Intel Xeon Silver 4216 16 core. In the end the amount of cameras does matter to our problems witnessed it can happen with simply 1 camera. The problems are not related to our application since it can be reproduced with vendor original test software (even without storing anything). So it is rather a latency than a bandwidth problem. From time to time there are single frames lost when the system is not configured for high speed aka CONFIG_HZ. Unfortunately we can not track it easily and have not possibility to influence the driver itself. But from our observation it is like the Linux system takes some brakes from time to time to manage interrupt handlers for the network stack. Then the camera buffers can not be processed by the driver in time and are lost. I can not explain why 1000 MHz instead of 250 MHz is making this difference. We have tried to optimize almost all others things thinkable like TCP buffers/network card driver and so on, maybe IOWAIT is an issue to be considered further but we really do not storing at all when we test... As I said I am limited in time to setup a complete test environment and going ground deep. All I can say the preempt kernel at 1000 MHz is working well. I hope this gives some insight and can be used as feedback from the field to all have worked in the Linux systems, thanks for this and thanks Pete for making this kernel. BR Thomas On 6/13/21 12:42 PM, Hans-Peter Jansen wrote:
Am Montag, 7. Juni 2021, 11:59:20 CEST schrieb Hannes Reinecke:
On 6/3/21 11:37 AM, Thomas Hartwig wrote:
I am wondering if there is any kernel available by default which offers kernel interrupt timer (CONFIG_HZ) at 1000 Hz. I checked preempt in 15.2 but there it is 250 Hz. Why this is kept at 250 Hz there?
Thomas, I do build some special kernels in this regard here:
https://build.opensuse.org/project/monitor/home:frispete:kernel
The preempt flavor is using CONFIG_HZ_1000 (of course).
For now, I build this kernel for TW only (target: openSUSE_Tumbleweed_Kernel_stable). It should work with Leap as well, but I can add other targets on request. To be honest, I build the kernels for my openSUSE zoo in an internal build service (for other reasons).
The kernel is based on
https://github.com/openSUSE/kernel-source/commits/stable
With 2 scheduler changes *rebased*:
https://github.com/frispete/kernel-source/tree/stable
https://github.com/frispete/kernel-source/commit/ eff66ed807d15a93ee71e192ba1ed7394dd5e917
https://github.com/frispete/kernel-source/commit/ 1affceb6384e74af3027599a17113a5fe04fd835
I would be honored, if you could give this build a try.
Please note, that these kernels are signed with my build key, which might trick UEFI into complaints and forcing you to add another certificate.
As you can see, I try to stick to the "official" workflow, which makes dealing with such changes a breeze.
Primarily for historical reasons; 250 Hz was found to be a good compromise between interactive and non-interactive tasks.
Sure Hannes, but with the advent of preempt, there's a new opportunity to split this compromise into:
default: voluntary preempt, optimized for non-interactive tasks, maximum throughput and efficiency
preempt: full preempt, optimized for low latency, less maximum performance in favor of optimal interactivity
At least in my modest tests, the preempt variant with HZ=1000 provides a better user experience on busy desktops *and* crowded servers.
Probably HZ=1000 is a red herring here, but even my poor Gen-1 X1 Carbon runs happily with my preempt kernels without visible adverse effects in battery endurance (which is pretty limited in this edition anyway). At least, it beats a calm Win10 desktop easily..
Of course, this doesn't replace a wider investigation, but we should try to make the most of the possibilities of two different versions.
I would like to see the preempt variant to use advanced CPU and compiler optimization techniques as well, but didn't dived into this yet.
What could be achieved can be seen here:
https://www.phoronix.com/scan.php?page=article&item=spring-2020-distros&num=1
We should take a leaf out of the Clear Linux* Project's book.
Best, Pete
Am Mittwoch, 16. Juni 2021, 11:16:50 CEST schrieb Thomas Hartwig:
Hi Pete,
thank you very much for the information and your work, I tested the preempt kernel 5.12 and it is performing very well.
Glad to hear that. I tend to delay the kernel version bumps a bit, but please use keeppackages=1 on that repo. "eg. zypper mr -k repo"
I think I can use these in production environments as well. This is good.
Rest assured that when I know someone is using these builds in production, I take extra care with them. My usual workflow is fetching from the opensuse kernel, rebasing, and pushing to this project. The packages in my local OBS are linked from there.
It would be nice to have some for distribution releases 15.2/15.3 but as long as the repository is isolated for the kernels only I can use the Tumbleweed version for sure.
The Leap builds have different issues, that are manageable, but if the TW build do for you, please go for it.
Meanwhile I want to give some more technical background to the issues monitored. Please note I am not a kernel developer nor an expert. Instead I am an application developer with extended system knowledge and sometimes vertical hardware diving but mainly I am locked to application development, this is why I am limited in time and know-how what is going on specific kernel versions. The systems I work with are specialized video capturing systems working with industrial high speed cameras based on GigE (Basler/Pylon software driver). All this is TCP/IP stack based, so IMHO this is the most critical section. The systems are storing video frames in memory and these are further processed in complex multi-threaded applications. Simply to give some numbers here which are really impressive what a Linux system is capable of: 6 cameras are streaming at 4000 frames per second each with a bandwidth of 100 MB/s which is handled by a fiber optic network card X710. So roughly 600 MB/s are handled. The CPU is an Intel Xeon Silver 4216 16 core. In the end the amount of cameras does matter to our problems witnessed it can happen with simply 1 camera. The problems are not related to our application since it can be reproduced with vendor original test software (even without storing anything). So it is rather a latency than a bandwidth problem. From time to time there are single frames lost when the system is not configured for high speed aka CONFIG_HZ. Unfortunately we can not track it easily and have not possibility to influence the driver itself. But from our observation it is like the Linux system takes some brakes from time to time to manage interrupt handlers for the network stack. Then the camera buffers can not be processed by the driver in time and are lost. I can not explain why 1000 MHz instead of 250 MHz is making this difference. We have tried to optimize almost all others things thinkable like TCP buffers/network card driver and so on, maybe IOWAIT is an issue to be considered further but we really do not storing at all when we test...
Wow, that sounds like real fun. And bit dance. This asks for playing with qdiscs and NIC offloading of course. Probably not applicable, but wasn't SCTP invented for this area.
As I said I am limited in time to setup a complete test environment and going ground deep. All I can say the preempt kernel at 1000 MHz is working well.
This is valuable feedback of course, even if not everyone likes it. While preemption is on the way of getting a dynamic boot option, HZ isn't as far as I know. Cannot imagine giving up on const'ness of HZ. This is a strong vote of a separate preempt flavor. However, you should test the official default (TW) kernel with the preempt option, once it appears, as well, if time permits.
I hope this gives some insight and can be used as feedback from the field to all have worked in the Linux systems, thanks for this and thanks Pete for making this kernel.
My pleasure and good luck, Thomas! Best regards, Pete
BR Thomas
participants (5)
-
Hannes Reinecke -
Hans-Peter Jansen -
L A Walsh -
Takashi Iwai -
Thomas Hartwig