search

LSTS / glued

GNU/Linux Uniform Environment Distribution
GNU General Public License v2.0
13 stars 13 forks source link

Adding support for PREEMPT_RT #27

Closed krisklau closed 8 years ago

krisklau commented 8 years ago

Hi,

I wanted to test adding the RT patch to the kernel we use in glued, and run some benchmarks with cyclictest to see the difference in latencies.

By applying the rt patch to 3.14.58 on a beaglebone black, and using the following benchmark command: cyclictest -l1000000 -m -n -a0 -t1 -p99 -i400 -h400 -q I got the following:

results

vanilla: Total: 001000000 # Min Latencies: 00007 # Avg Latencies: 00009 # Max Latencies: 02934 rt-patch:Total: 001000000 # Min Latencies: 00007 # Avg Latencies: 00009 # Max Latencies: 00041

which I find interesting enough to do some further tests.

I open this PR to start a discussion on:

  1. Using the rt patch at all, is it necessary?
  2. If so, find a clever way to incorporate in the build system.

Attached is a suggestion for 2. As can be seen in https://www.kernel.org/pub/linux/kernel/projects/rt/3.14/, not all releases gets a rt-patch, which gives a couple of drawbacks of the suggested method. This means that if one wants to use the newest vanilla kernel (e.g. 3.14.63), that may not have an rt patch yet, several files needs to be duplicated. (configs, linux-patches, linux-headers? etc). Ideally, I guess the original version could be tracked, and copied from the appropriate locations instead.

The file rules/linux/preempt_rt.bash keeps track of the kernel version and rt version, and overrides from default.bash. Also, some code is duplicated to add functionality to the functions configure() and post_unpack(), which is not ideal imo. Maybe add some additional hooks in default.bash, like post_configure(), and post_unpack_patch()? (just in the linux-package, called by the appropriate functions in default.bash)

Thanks for all inputs, comments and suggestions!

Regards, Kristian

rasmartins commented 8 years ago

We have used the RT patches in GLUED many years ago. Can you issue separate pull requests, one for the rt-tests (which can be easily merged), one for the kernel, and another for ntnu-b2xx ? Since we are using LTS kernels I guess we can avoid duplicating the patches using only the major and minor versions.

krisklau commented 8 years ago

Hi, Thanks, will do.

Good idea. Do you reckon we change the paths to 3.14.xx, or a scheme to apply the newest patch? Do you remember why you stopped using the RT patches?

Kristian

krisklau commented 8 years ago

For instance something like this: https://github.com/krisklau/glued/commit/414f88aef1d8a0daeec38f0ec63d384990b1075c

rasmartins commented 8 years ago

Give me some time to go through this. We stopped using the -rt patches because our hardware was not servicing interrupt requests fast enough thus leading to data loss.

rasmartins commented 8 years ago

Take a look at the branch feature/linux-rt. I think this approach should suffice.

krisklau commented 8 years ago

Hi,

I really like that approach, nice. Tested and verified.

Do you know of another mirror for the rt-patches? They seem to move the patches from the main folder https://www.kernel.org/pub/linux/kernel/projects/rt/3.14/ to older/ after each release.

Kristian

rasmartins commented 8 years ago

Hi,

I will mirror the patch used by GLUED in our servers.

On Fri, Mar 25, 2016 at 2:21 PM, krisklau notifications@github.com wrote:

Hi,

I really like that approach, nice. Tested and verified.

Do you know of another mirror for the rt-patches? They seem to move the patches from the main folder https://www.kernel.org/pub/linux/kernel/projects/rt/3.14/ to older/ after each release.

Kristian

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/LSTS/glued/pull/27#issuecomment-201306099

rasmartins commented 8 years ago

Please re-submit your config files