From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7007435916639731712 X-Received: by 2002:a17:906:4817:: with SMTP id w23mr1197823ejq.363.1631727578741; Wed, 15 Sep 2021 10:39:38 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:4882:: with SMTP id v2ls267617ejq.9.gmail; Wed, 15 Sep 2021 10:39:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxN3T/vjF+Yxv5iiAEBT60ZBRJrnyCvwx+2VvF/Ieh9fDoByLFylUfQApjnVRmffnCDYyvN X-Received: by 2002:a17:906:6d5a:: with SMTP id a26mr1299768ejt.162.1631727577621; Wed, 15 Sep 2021 10:39:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631727577; cv=none; d=google.com; s=arc-20160816; b=I2w6QbSGXShye1kEG/Z1K1RnFZqs5QrGUDJdvxR6sJA4kuy5FY4Wn8gQsFVKVxP6oX 2fZyY/aD4/CRVDBSmerWQGi+jc5TopOumO5bR/cB08Hw7Hh/HzeKMgNiObZuWIxwbur5 0evVrWCUzwUjuMA/Oeqgl4lyaELoz40yCt8mSsQ8vcimDQwMJ3YLLy3uchRSfE53ApNB CLFj4cnV4ZDoMUJfnDLf+j60T24ymPT3FKxxJ4krLgImIbJxl2yXA71eYwdhT4mjyThZ D293a4A1T0HMyRg48TXGoL0uE/6ICfSIDdKMScuht8DNHXZqBVnhIXvD8GdW+GxHnGMb 2+Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=4rShg1HXXKBuTbTShZMTkpBUkp02JYEFQM2b8Wkfr70=; b=q6X/GyR9yf1L5Vg4Uc4pqbC8SaGrxh+qZWVMhM5gPay+iNceXT57U/L6Qi9wkksBRI eJfj++E44lgPL9kptqpfTJhxosuUNuzIeAEVQ+4ruw2RXTqO/YvJ7YosSy/nlS3BeIyg EuoMtodIVFOE0Qp9QsVJm547AupLzlzXJSFxqKXvIDKXNxLvmmMwi5ogqLLetXVI68rB MjYnypuTV/D//OTVS3QTAVfOE/c7jGm7V25vjoBwIkaf/I0L0QS77qEvWPFD7ftYHyfK NZLGqVaOTvPlLSnvk4IwzzJxJHpx9fNITu2SYr9HOS2a/H4RJAg+vWgPsEVqu//TmwIp NzOQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id r23si290867edy.3.2021.09.15.10.39.37 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Sep 2021 10:39:37 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 18FHdb5P001526 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 Sep 2021 19:39:37 +0200 Received: from [167.87.79.72] ([167.87.79.72]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 18FHdaLv001772; Wed, 15 Sep 2021 19:39:36 +0200 Subject: Re: [PATCH 0/2] Support for ccache To: Henning Schild , Uladzimir Bely Cc: isar-users@googlegroups.com References: <20210913151009.28655-1-ubely@ilbers.de> <20210915184318.7c32c158@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: Date: Wed, 15 Sep 2021 19:39:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210915184318.7c32c158@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: gGKjzKvUayib On 15.09.21 18:43, Henning Schild wrote: > 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? It's self-regulating, and you can set an upper size limit in ~/.ccache/ccache.conf. I'm running it locally for ages without observing issues. > > 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 ... It is by nature as it has to support make -j as well. ccache is a rather solid, actually old technology. When we use it in lock-step with the compiler shipped by the same debian release, we are on a safe ground. If that qualifies for default-on, I don't know, but at least "recommend-on". Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux