From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7007435916639731712 X-Received: by 2002:a2e:b894:: with SMTP id r20mr868480ljp.238.1631724201505; Wed, 15 Sep 2021 09:43:21 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:10e:: with SMTP id a14ls204606ljb.4.gmail; Wed, 15 Sep 2021 09:43:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvHRjISIQNctaa7FygXi+YMrpyWgVceq9if7H4IaKMt4CuVHGQwv1vkwa9g1Wq0MGmf6Hs X-Received: by 2002:a2e:b88b:: with SMTP id r11mr819477ljp.167.1631724200461; Wed, 15 Sep 2021 09:43:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631724200; cv=none; d=google.com; s=arc-20160816; b=w6uUoRaqRbUzlcOvgYuFp8Hmrzlrwp7nqSy1n8H6cW6pRxRba3YzrnuGwHoMcoBHqS zmfNoCp3sivrYMBvyg8G09VgBxmhua9Kc4+KPA1BYsHZGVQrl+XLDjTk0l52C1IOJxIK l/BJJ1G8WjPUUugHoqt+RklWawEiEvirFV/pIGFr+f594AIlH5sCRuc/bh+nlWIPwTjA sU/pAHyQdDh2n04+mdG3pCCNAuYO71GhpEDjkaty/c4abMSpxZqgll9dPKOmLfnHr/7B cVjCjeYmmQW8akY/Fs7yJi/U6ntxf/DS02Ehd3BFfK/rbyA2a2TUSahLs6VxhvD52KKI P79g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=7VRRFGdJurczxpH4Q8nkSDFbRkAVT26DeHgnV3xdCDk=; b=OnxZHd+Ur3Nt2uKj8HKLwtGYMnG9FkXXw8WvPSUgeXPoFDW3D2aZYXxAb+vn8J+XI4 fHgY6wDu4V9eZ32O0Q5A3wUP/grHKOpJu22sdHZpXqIYxCN/appB/ka/zBrHCOH6u6yM uGJVf1MKpQlu35yaLccyHhoRWvFcdV5XbfGAt6WAcso49i3ROcp19mFPVddIFr/hYpxW u+Q8ndsboZI79tBoz6PAgQ799iz6FxyXPtVBWj2FMAC+yZ1pvCVz8Y+x/VgsIEcdz1Y2 gKQdcMpwwpD4H6oJwATZFAGCnhfWbKtkdA79qti4WDROxmyJEGUkaluUyJ/REmA6Ha7w vB2A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id l20si158821lfg.9.2021.09.15.09.43.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Sep 2021 09:43:20 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 18FGhJF0001013 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 Sep 2021 18:43:19 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.0.59]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 18FGhJjU022855; Wed, 15 Sep 2021 18:43:19 +0200 Date: Wed, 15 Sep 2021 18:43:18 +0200 From: Henning Schild To: Uladzimir Bely Cc: isar-users@googlegroups.com Subject: Re: [PATCH 0/2] Support for ccache Message-ID: <20210915184318.7c32c158@md1za8fc.ad001.siemens.net> In-Reply-To: <20210913151009.28655-1-ubely@ilbers.de> References: <20210913151009.28655-1-ubely@ilbers.de> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: uwdyhuJq3ZKg This looks like a very good addition to the sstate feature that has been brewing in our basement. The combination would be really cool. With sstate we are already seeing drastic speedups because tasks get skipped over. But if a long compile task can not be taken from the cache, this guy could come in as just the helper we needed here. We will look into combining the two and see when our in-house stuff is ready for sharing. Our biggest issue still is "eviction". We decided to solve that with cron and wipe the whole cache every night. For sstate that is important because if debootstrap rootfss (something we cache) get too old, they would need "apt-get update/upgrade" ... so we only cache for so long. Another reason for eviction might not just be age but space. How to make sure that ccache does not grow forever? Instructions on how to evict are missing in the documentation. Or is it somehow self regulating? The next question is whether it is thread-safe, meaning many instances of isar/bitbake can use it at the same time. Possibly from multiple machines sharing that cache folder ... Henning Am Mon, 13 Sep 2021 17:10:07 +0200 schrieb Uladzimir Bely : > Some custom user packages built from sources may be written in C/C++. > Using ccache will help decrease build time in case they are rebuilt. > > For example, building `mc:stm32mp15x-buster:linux-mainline` during the > test took 28 minutes at second build with ccache enabled in > comparison with 115 minutes of first build. > > Uladzimir Bely (2): > meta: Support for ccache for custom packages in buildchroot > doc: Add section about ccache usage > > doc/user_manual.md | 16 +++++++++++++ > meta-isar/conf/local.conf.sample | 5 ++++ > meta/classes/buildchroot.bbclass | 6 +++++ > meta/classes/ccache.bbclass | 23 > +++++++++++++++++++ meta/classes/dpkg.bbclass | > 12 +++++++++- .../buildchroot/buildchroot.inc | 1 + > .../buildchroot/files/build.sh | 6 +++++ > .../buildchroot/files/common.sh | 1 + > 8 files changed, 69 insertions(+), 1 deletion(-) > create mode 100644 meta/classes/ccache.bbclass >