public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Schmidt,
	Adriaan (T RDA IOT SES-DE)" <adriaan.schmidt@siemens.com>,
	"Schild, Henning (T RDA IOT SES-DE)" <henning.schild@siemens.com>,
	Anton Mikanovich <amikan@ilbers.de>
Cc: "isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: Re: [PATCH] CI: Add sstate-cache testcase
Date: Tue, 2 Nov 2021 08:55:18 +0100	[thread overview]
Message-ID: <075effef-5258-346a-51cf-ad6ddcb68f91@siemens.com> (raw)
In-Reply-To: <DB6PR1001MB122159B1F60424E406E43E84ED8B9@DB6PR1001MB1221.EURPRD10.PROD.OUTLOOK.COM>

On 02.11.21 06:57, Schmidt, Adriaan (T RDA IOT SES-DE) wrote:
> Henning Schild, Donnerstag, 28. Oktober 2021 20:22:
>> Am Thu, 28 Oct 2021 20:22:58 +0300
>> schrieb Anton Mikanovich <amikan@ilbers.de>:
>>
>>> 28.10.2021 18:34, Jan Kiszka wrote:
>>>> On 28.10.21 17:20, Anton Mikanovich wrote:
>>>>> Test rebuild time improve after cleanup to be sure sstate-cache
>>>>> works.
>>>>>
>>>>> Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
>>>>> ---
>>>>>   testsuite/build_test/build_test.py | 40
>>>>> ++++++++++++++++++++++++++++-- 1 file changed, 38 insertions(+), 2
>>>>> deletions(-)
>>>>>
>>>>> diff --git a/testsuite/build_test/build_test.py
>>>>> b/testsuite/build_test/build_test.py index d39c10c0..244f6fc0
>>>>> 100644 --- a/testsuite/build_test/build_test.py
>>>>> +++ b/testsuite/build_test/build_test.py
>>>>> @@ -1,9 +1,9 @@
>>>>>   #!/usr/bin/env python3
>>>>>
>>>>> -import os
>>>>> +import os, time
>>>>>
>>>>>   from avocado import skipUnless
>>>>> -from avocado.utils import path
>>>>> +from avocado.utils import path, process
>>>>>   from cibase import CIBaseTest
>>>>>
>>>>>   UMOCI_AVAILABLE = True
>>>>> @@ -206,3 +206,39 @@ class ContainerSdkTest(CIBaseTest):
>>>>>           targets = ['mc:container-amd64-stretch:isar-image-base']
>>>>>
>>>>>           self.perform_container_test(targets, 'do_populate_sdk')
>>>>> +
>>>>> +class SstateTest(CIBaseTest):
>>>>> +
>>>>> +    """
>>>>> +    Test rebuild speed improve with sstate-cache
>>>>> +
>>>>> +    :avocado: tags=sstate
>>>>> +    """
>>>>> +    def test_sstate_rebuild(self):
>>>>> +        speedup_k = 2.0
>>>>> +
>>>>> +        targets = [
>>>>> +            'mc:qemuamd64-bullseye:isar-image-base'
>>>>> +                  ]
>>>>> +
>>>>> +        # Cleanup everything before build
>>>>> +        build_dir = self.params.get('build_dir',
>>>>> +                    default=os.path.dirname(__file__) +
>>>>> '/../../build')
>>>>> +        process.run('rm -rf ' + build_dir + '/sstate-cache',
>>>>> sudo=True)
>>>>> +        self.deletetmp(build_dir)
>>>>> +
>>>>> +        start = time.time()
>>>>> +        self.perform_build_test(targets, 1, None)
>>>>> +        first_time = time.time() - start
>>>>> +        self.log.info('Non-cached build:' + str(round(first_time,
>>>>> 2))) +
>>>>> +        # Cleanup everything but cache files
>>>>> +        self.deletetmp(build_dir)
>>>>> +
>>>>> +        start = time.time()
>>>>> +        self.perform_build_test(targets, 1, None)
>>>>> +        second_time = time.time() - start
>>>>> +        self.log.info('Cached build:' + str(round(second_time,
>>>>> 2))) +
>>>>> +        if first_time / second_time < speedup_k:
>>>>> +            self.fail('No speedup after rebuild with
>>>>> sstate-cache')
>>>> Is there no better way than measuring time to test if sstate was in
>>>> place? Maybe some hit/miss statistics?
>>>>
>>>> Jan
>>>>
>>> I've tried to find some Avocado API to access final testcase
>>> statistics from within other testcase but didn't find so far.
>>> Any advice is welcome.
>>
>> sstate hit rates are in the bitbake logs, i hope avocado can open
>> artifacts
> 
> You want to look for the line "Sstate summary", which is shown at the beginning of the bitbake run, e.g.:
> 
> Sstate summary: Wanted 121 Local 121 Network 0 Missed 0 Current 0 (100% match, 0% complete)
> 
> But in a test it's probably better to examine log.task_order and check which tasks were executed.
> 
>> But this is infra ... we will see when it fails and do not have to test
>> that.
> 
> It's worth running some tests to see that builds succeed with artifacts taken from cache. I can imagine something like:
> 
> - Build image to populate cache
> - Remove TMPDIR
> - Rebuild the image. Should have 100% cache hits. (This would take the target rootfs from cache, and the buildchroot required for image-building)
> - Remove TMPDIR
> - Build a single package (that was already contained in the image). Should have a cache hit, and only dpkg_build_setscene and deploy_deb should run (plus minimal steps to initialize isar-apt).
> 
> And optionally:
> - Remove TMPDIR
> - Force rebuild of one package (e.g. by deleting its sstate artifact)
> - Rebuild the image (should take the buildchroot and all but the one package from cache, and rebuild the one package and the image)
> 

BTW, we likely now also need a cleansstate target, like OE has.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

      reply	other threads:[~2021-11-02  7:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 15:20 Anton Mikanovich
2021-10-28 15:34 ` Jan Kiszka
2021-10-28 17:22   ` Anton Mikanovich
2021-10-28 18:21     ` Henning Schild
2021-11-02  5:57       ` Schmidt, Adriaan
2021-11-02  7:55         ` Jan Kiszka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=075effef-5258-346a-51cf-ad6ddcb68f91@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=adriaan.schmidt@siemens.com \
    --cc=amikan@ilbers.de \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox