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 C60FF189919 for ; Thu, 24 Apr 2025 13:52:35 +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=1745502755; cv=none; b=X4o0I3hfxKPzRbp5YcIJRqD0WsscrgnHvW38/6fRiPZxmqdPcB4Ds8htNcwoZC5iWat1H3VaoeN2A14cCTU1+p/QhysCusmZfYk1Aoqt4WtuEV5fKG0jC1Ynny77qV7Hlk+SfllFHeR36t+IslWqHu3NuAkawZ1qhUNwGwQ4JeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745502755; c=relaxed/simple; bh=zxDRnemsObu5OiMUBBx9i6mXm/PYrYxo9oGQhIBmNL4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=M16taqc5PvtQEQgLaAcEFhGb24s4I4r3wAbWFB/wRPhoeBb/j2T1kZb8+Exivy6zU5XgYcBjWR4bACdDuXAA16iLIIQFGcGweHR2PCfWX89kxMtrHH++xfnkCCcFYDSKeKQA9kmEfDMwcWk1PVbxmoDJLaZdFVkcbR6yCAJiEjs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ogheH/wk; 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="ogheH/wk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B961DC4CEE3; Thu, 24 Apr 2025 13:52:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745502755; bh=zxDRnemsObu5OiMUBBx9i6mXm/PYrYxo9oGQhIBmNL4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ogheH/wk7rWh6kXZmZcbQEzffSdrknoxS9hXhHM1VjcgkfH2wMYpDsemuU6gguifA mR0qnjSxbo8hOqnBE/8AqNezjMuivYT/80PVHxEK8h0HCFwhF3m+DTueDpN3No/fTn ItxNm/e7lcaa0dVjNxogXRU+Ec89mEfKkszWmQIkLEhWEH+X6U9HrSimpvKeCFlDeg 1x9MI+IE4pXqDOE1xtOWNuJn6f/UVRtwgA+FUmpmfa7YUi7FV/AM2xO5xMeUGWBWGB +qMrXDPF+di34mvjsUA49W5MM5GQNYXkJIYYYKCYtYttgnkJ/jLmsCjlpdDDAJl+1t cZrUiPPYP5B5A== Message-ID: Date: Thu, 24 Apr 2025 09:51:36 -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> <952de7ec-1e33-4ccb-9923-33fa881aee55@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 1:28 PM, Daniel Gomez wrote: > On Wed, Apr 23, 2025 at 09:36:37AM +0100, Chuck Lever wrote: >> 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. > > Build artifacts can also be shared between the build nodes instances as long as > they are the same following reproducible builds [1] > > [1] > https://docs.kernel.org/kbuild/reproducible-builds.html#reproducible-builds > > But all right, I understand this is a separate topic and having ccache/redis/ > reproducible build features is something we can work with and extend as opt-in > features in kdevops and/or this new workflow. > > Thanks for the feedback. > >> 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. > > I guess the benefits will depend on every user, kernel config and how the cache > is exposed. > >> >> 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. > > That would be great. > >> >> 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. > > I'm usually more in favor of having standalone playbooks. But I see here > the potential of merging the features rather than having them separate. My > suggestion is to refactor bootlinux role into separate tasks/ feature>. Where the features are build_linux, artifacts, package creation, etc. I did something similar to playbooks/roles/gen_nodes. I can experiment and post some ideas. -- Chuck Lever