From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7520361FFE for ; Wed, 23 Apr 2025 13:36:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745415399; cv=none; b=mvuNm38mcUOSB2etSRTPubls4DzodOhcPDYrWUiEC4WD7z6NVYHT1HnVIEzjDdUgt8qEFRVjdtnm4DWcoIH+zeAVxEh8yDOktnU9pOGUWj1Tx8OdIa8Jd+q70mdyYWykrRuSZ0Twy1lDP+7JVH6nSLii4GngceD9Z+gbsKOwfRc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745415399; c=relaxed/simple; bh=0Px2AFA3dPmSqaLJeTp06wzYAoBLlgJbAwxZuRf7Zfo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ek3VLOVcx8uLHFyUXz9X5x8xlCcBceEEch+pGTq8qt+gJCQQWJzWXd16qXGc2lAA5cY7835kIkjvYKInBv8e+9enMr6ogw7DNg2AKAPoaCXWGcRiLjEURBzssqPt/trJAb6Fseqyv+yrRZmC7+xOobcSefI2yySHPfBAD+lRnes= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R3NGc2LI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R3NGc2LI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E62CC4CEE2; Wed, 23 Apr 2025 13:36:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745415398; bh=0Px2AFA3dPmSqaLJeTp06wzYAoBLlgJbAwxZuRf7Zfo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=R3NGc2LICGhFgSnVnafZpvgn/cxAodadxiJMcDy52LDbTNuvtjDftnXkimVReziS0 PcL26R9g+Utyzp88C55wqSdgyWgHjWCiXt2fwhtJhZsMwZTTBSuL2BDSKX5GdbgOz7 k73O3cHtuxnlYhgGI+Qz1rma285e3Mrdd3KiHpueujy2J9tt6p5W77uWYU0bt2ENvz 7qluhvx9liWYG3LLfn4B/jTvBdlZGXVMcf1SCLmgPIsUCE/aHxZ1mmvHvhoZMDWDjr Cd1/OZ8w8yis7cHA2p8vHBkbfpbZy1b6u4z4R97IH/r+SkWBwnq9hyu+A3QrBnGL5T K2lQqLIYar3QA== Message-ID: <952de7ec-1e33-4ccb-9923-33fa881aee55@kernel.org> Date: Wed, 23 Apr 2025 09:36:37 -0400 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/3] Build once, test everywhere To: Daniel Gomez Cc: Luis Chamberlain , Scott Mayhew , kdevops@lists.linux.dev, Chuck Lever References: <20250422154906.526319-1-cel@kernel.org> Content-Language: en-US From: Chuck Lever Organization: kernel.org In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/23/25 8:34 AM, Daniel Gomez wrote: > On Tue, Apr 22, 2025 at 11:49:03AM +0100, cel@kernel.org wrote: >> From: Chuck Lever >> >> With apologies to the Java folks. >> >> I've been looking for ways to make our workflow runs more efficient >> because my lab resources are limited, and moving to the cloud costs >> money per CPU second. >> >> One thing that seems like an obvious win would be to build the test >> kernel one time (for example, after a merge/pull request), then >> re-use that kernel binary for all the workflows we want to run on >> it. > > What about rebuilds between iterations? > I think an extra step to improve that build time could be adding support for > ccache in our kernel builds. Would it make sense to extend this in the future to > enable a redis node? > > https://github.com/ccache/ccache/wiki/Redis-storage > > With the workflow suggestion below, I'd then do: > > 1. Bring up a redis node guest > 2. Bring up a kernel builder node that pulls from redis node ccache > 3. Push redis artifacts to control host (for later sync up) and destroy redis guest > 4. Push kernel package to control host So I've asked our internal testing folks about using ccache to speed up kernel builds. There were various reasons not to do this, one of which is we want to have a clean trustworthy and repeatable kernel build to test with. I'm not sure I have a specific technical argument against using ccache except that our builder node is ephemeral, making its ccache usable for only a single build. A Redis storage node might solve that issue. However I wonder if the time it takes to bring up the node, reload its storage, then after the build save the redis artifacts and destroy it might wipe out any benefit. With libvirt guests we can save several minutes by doing the guest bring up in parallel (via Ansible) instead of serially via a shell script. I've got some ideas about that. > That said, all this new workflow makes sense to me. I guess instead of > duplicating the bootlinux role into build_linux I'd like to see a linux > role that handles build location (localhost/specific guest), output package > generation or not, deployment, etc. Does that make sense to you too? The bootlinux role has grown a slew of special cases over the years, so I'm in the mood to help reorganize it a little. At least split it into a role that handles the kernel build, and one that handles the minutiae of installing the builds on test runners. I'm not quite following your suggestion, but I'm interested in hearing more detail. -- Chuck Lever