Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32
Hi Jan, On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote: > Hi Sepp, > > On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote: > > Hello! > > > > To improve the testing situation for the 4.4 Kernel family on ARM32, I > > created a set of layers [1] for OpenEmbedded. Currently the features are > > rather limited: > > > > - only the Morty branch exists, as this one natively includes Linux 4.4 > >and therefore the GCC version etc. matches. > > To my best knowledge, there is no dependency (yet) between a too new > compiler and kernel 4.4. We are building 4.4-cip with pyro, e.g. Yes, I agree that pyro and rocko should probably not give any major trouble. Yet, something in the back of my head tells me that thud and maybe sumo will be problematic. Will investigate and report! > > - only one BSP layer so far, namely the Beaglebone. This was chosen for > >two major reasons: a) it is supported well enough in 4.4. to not need > >additional patches which might introduce new issues, and b) it is > >hardware that I have here ready for testing. > > I was thinking about which ARMv7 board to add to xenomai-images (enabling > qemu will be first, though), and that is a good candidate there as well. > > Another half-done topic here: CI builds. For that, the BB defconfig could be > useful too. My local tinkering of xenoami-images to create a qemu-armhf build is still in progress. But yes, we should have a build there too. But I don't think the BB defconfig I'm using at the moment is really suited for xenomai testing. I'll certainly need to tinker with it some more. > > > - no higher automation like a kas cofiguration so far. Yet this probably > >will be the first limitation to be gotten rid of. > > > > My current planning is to add a set of testing scripts based of > > Philippe's suggestion, and run that suite on each new release for a > > couple of days and post the results to the ML. > > That sounds very helpful! We should try to keep common parts (anything > unrelated to the image build system) in the core so that we can reuse that > in xenomai-images as well. In the end, it would probably just be something like "xeno-test-long" > > > > > Preliminary results to kick off things: > > - xeno-test completes successfully > > - latency -t0 under load maxes at ~58µs > > - latency -t2 under load maxes at ~18µs > > > > Great! According to [1], we could then tag 63637800 also for ARM? Or do you > want to run more of the tests you have in mind first? Given my current testing experience, I would like to not say yes or no, as I'm not knowledgeable enough to judge. So please decide yourself upon the given information, with those additional "hints": - xeno-test "only" runs for 15minutes by default. - the latency tests I did were not really more long-lived, I don't think any one exceeded 30minutes. - it will be at least two more weeks until I have the long-run results. Could also be three. So if you want to tag rather soon, I can't rally help more. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
[xenomai-images][PATCH 1/3] customizations: Remove obsolete cleanup and chown
From: Jan Kiszka
Isar does that for us now.
Signed-off-by: Jan Kiszka
---
recipes-core/customizations/customizations.bb | 4
1 file changed, 4 deletions(-)
diff --git a/recipes-core/customizations/customizations.bb
b/recipes-core/customizations/customizations.bb
index fd41a09..e35c0a5 100644
--- a/recipes-core/customizations/customizations.bb
+++ b/recipes-core/customizations/customizations.bb
@@ -21,13 +21,9 @@ SRC_URI = " \
DEBIAN_DEPENDS = "passwd"
do_install() {
- sudo rm -rf ${D}/etc ${D}/root
-
install -v -d ${D}/etc/network/interfaces.d
install -v -m 644 ${WORKDIR}/ethernet ${D}/etc/network/interfaces.d/
install -v -d ${D}/etc/sysctl.d
install -v -m 644 ${WORKDIR}/99-silent-printk.conf ${D}/etc/sysctl.d/
-
- sudo chown -R root:root ${D}/etc
}
--
2.16.4
[xenomai-images][PATCH 2/3] linux-xenomai: Fix arm64 SRC_URI
From: Jan Kiszka Use the stable branch, the split one no longer exists. Signed-off-by: Jan Kiszka --- recipes-kernel/linux/linux-xenomai_4.14.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-kernel/linux/linux-xenomai_4.14.bb b/recipes-kernel/linux/linux-xenomai_4.14.bb index 1bc139c..c668d75 100644 --- a/recipes-kernel/linux/linux-xenomai_4.14.bb +++ b/recipes-kernel/linux/linux-xenomai_4.14.bb @@ -15,7 +15,7 @@ SRC_URI_append_amd64 = " git://gitlab.denx.de/Xenomai/ipipe-x86.git;protocol=htt SRCREV_amd64 = "5dec184b4c190bd3ef4d448fc80c7f2251cfd744" PV_amd64 = "4.14.78+" -SRC_URI_append_arm64 = " git://gitlab.denx.de/Xenomai/ipipe-arm64.git;protocol=https;branch=v4.14.71-split" +SRC_URI_append_arm64 = " git://gitlab.denx.de/Xenomai/ipipe-arm64.git;protocol=https;branch=stable/4.14.71-arm64" SRCREV_arm64 = "d24e3f9e425af92f4a181306d22d4b799e71a370" PV_arm64 = "4.14.71+" -- 2.16.4
Re: [PATCH] cobalt/sched-quota: Account for already consumed time on limit update
On 26.11.18 13:22, Jan Kiszka wrote: On 25.11.18 18:14, Philippe Gerum wrote: On 11/21/18 5:59 PM, Jan Kiszka wrote: If we change the quota value of thread group, we should take its already consumed time during the current cycle into account. So far, we refilled the budget blindly, which could have given the group an uncontrolled "peak". This commit first update the run_budget_ns of an active group and kills its limit timer. Then it refills run_budget_ns only with the remaining budget of the current cycle, taking the new quota as limit. Accumulated credits are still dropped - not worth to deal with their complexity in this scenario. Signed-off-by: Jan Kiszka --- Philippe, review would be appreciated. Looks good. Thanks. Applied to next now. ...and it will go into stable as well. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
[xenomai-images][PATCH 0/3] Cleanups & qemu-armhf target addition
Mostly brings the qemu-armhf target. See patches for other details. Jan Jan Kiszka (3): customizations: Remove obsolete cleanup and chown linux-xenomai: Fix arm64 SRC_URI Add qemu-armhf target .../files/ethernet => board-qemu-armhf.yml | 11 +- .../files/ethernet => conf/machine/qemu-armhf.conf |9 +- .../multiconfig/qemu-armhf-xenomai-demo.conf |9 +- recipes-core/customizations/customizations.bb |4 - recipes-core/customizations/files/ethernet |2 +- recipes-kernel/linux/files/armhf_defconfig | 7248 recipes-kernel/linux/linux-xenomai_4.14.bb |6 +- start-qemu.sh | 14 + 8 files changed, 7276 insertions(+), 27 deletions(-) copy recipes-core/customizations/files/ethernet => board-qemu-armhf.yml (54%) copy recipes-core/customizations/files/ethernet => conf/machine/qemu-armhf.conf (54%) copy recipes-core/customizations/files/ethernet => conf/multiconfig/qemu-armhf-xenomai-demo.conf (54%) create mode 100644 recipes-kernel/linux/files/armhf_defconfig -- 2.16.4
ipipe-arm64 kernel config questions
Is there a kernel config snippet available which contains only the real-time specific options of the ipipe-arm64 kernel? If so, could someone please point me to it? If not, could someone please make it available? I need it so I can merge it with the config I use in Yocto to build my customized Linux system. Background: Sometimes, I build my customized system to use the raspberrypi/linux kernel; other times I build it to use the ipipe-arm64 kernel. I need to merge the real-time specific options of the ipipe-arm64 default config into my existing default config for my Yocto build, such that I can have an acceptable minimal default config for ipipe-arm64. Currently, the two configs are wildly divergent, thus the desire to merge only the minimal config changes needed for ipipe-arm64 real-time benefits. If this is possible, I plan to use the Linux utility script merge-configs to achieve this. If this is not possible, I can provide the output of the diffconfig script, which shows a concise diff of the differences between the two config files. Given that, maybe someone could analyze that, and inform me as to which of the kernel options that are different or added for ipie-arm64are the ones that truly have an impact on real-time performance. Steve Pavao Korg R
Re: [PATCH] cobalt/sched-quota: Account for already consumed time on limit update
On 25.11.18 18:14, Philippe Gerum wrote: On 11/21/18 5:59 PM, Jan Kiszka wrote: If we change the quota value of thread group, we should take its already consumed time during the current cycle into account. So far, we refilled the budget blindly, which could have given the group an uncontrolled "peak". This commit first update the run_budget_ns of an active group and kills its limit timer. Then it refills run_budget_ns only with the remaining budget of the current cycle, taking the new quota as limit. Accumulated credits are still dropped - not worth to deal with their complexity in this scenario. Signed-off-by: Jan Kiszka --- Philippe, review would be appreciated. Looks good. Thanks. Applied to next now. I'm still struggling with writing a good test case for that. Absolutely untested, but what about doing this: calibrate some number crunching loop to have it running for a given time you would use as the initial quota value (e.g. 1s). Then, . set the initial quota value . run a test loop for 2/3 of the iterations spent in the calibration loop, . decrease the initial quota value by half . re-run the test loop, it should not have run more than half of the calibrated iterations (+/- some error margin and fluctuations). A broken quota implementation would have allowed 2/3 if IIUC. I think the difference was only visible in the cycle of the adjustment. It should have worked fine again on the next, clean round. Checking for the actual number of iterations performed during the second run could be done from a low priority thread which resumes when the test runner is dequeued as the quota expires. Both the test runner and the checker should be pinned on the same CPU. With QUOTA_PERIOD larger and not too close to the initial quota value, this should leave enough time for the low priority thread to check the result. I will think about that. It's annoying when tests turn out to be as complex - if not more - as the actual code they test. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32
On 26.11.18 15:30, Josef Holzmayr wrote: Hi Jan, On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote: Hi Sepp, On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote: Hello! To improve the testing situation for the 4.4 Kernel family on ARM32, I created a set of layers [1] for OpenEmbedded. Currently the features are rather limited: - only the Morty branch exists, as this one natively includes Linux 4.4 and therefore the GCC version etc. matches. To my best knowledge, there is no dependency (yet) between a too new compiler and kernel 4.4. We are building 4.4-cip with pyro, e.g. Yes, I agree that pyro and rocko should probably not give any major trouble. Yet, something in the back of my head tells me that thud and maybe sumo will be problematic. Will investigate and report! OK, understood. - only one BSP layer so far, namely the Beaglebone. This was chosen for two major reasons: a) it is supported well enough in 4.4. to not need additional patches which might introduce new issues, and b) it is hardware that I have here ready for testing. I was thinking about which ARMv7 board to add to xenomai-images (enabling qemu will be first, though), and that is a good candidate there as well. Another half-done topic here: CI builds. For that, the BB defconfig could be useful too. My local tinkering of xenoami-images to create a qemu-armhf build is still in progress. But yes, we should have a build there too. But I Oh, we might have worked in parallel, sorry: I've qemu-armhf for xenomai-images locally already (just started today). Will post later. don't think the BB defconfig I'm using at the moment is really suited for xenomai testing. I'll certainly need to tinker with it some more. Yes, configs is a good topic. I was playing with them a lot today, to get some output first, then to find some reasonable debug setup. Considering to have a "release" (measurement) and "debug" profile for configs. - no higher automation like a kas cofiguration so far. Yet this probably will be the first limitation to be gotten rid of. My current planning is to add a set of testing scripts based of Philippe's suggestion, and run that suite on each new release for a couple of days and post the results to the ML. That sounds very helpful! We should try to keep common parts (anything unrelated to the image build system) in the core so that we can reuse that in xenomai-images as well. In the end, it would probably just be something like "xeno-test-long" Preliminary results to kick off things: - xeno-test completes successfully - latency -t0 under load maxes at ~58µs - latency -t2 under load maxes at ~18µs Great! According to [1], we could then tag 63637800 also for ARM? Or do you want to run more of the tests you have in mind first? Given my current testing experience, I would like to not say yes or no, as I'm not knowledgeable enough to judge. So please decide yourself upon the given information, with those additional "hints": - xeno-test "only" runs for 15minutes by default. - the latency tests I did were not really more long-lived, I don't think any one exceeded 30minutes. - it will be at least two more weeks until I have the long-run results. Could also be three. So if you want to tag rather soon, I can't rally help more. OK, then I will not hurry. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
