On Sat, Nov 19, 2022 at 01:18:54PM -0800, Andres Freund wrote:
> > Also, if CompilerWarnings doesn't depend on Linux, that means those two
> > tasks will normally start and run simultaneously, which means a single
> > branch will use all 8 of the linux CPUs available from cirrus. Is that
> > intentional?
>
> I don't think that'd really make anything worse. But perhaps we could just
> reduce the CPU count for linux autoconf by 1?
I didn't understand the goal of "reducing by one" ?
Up to now, most tasks are using half of the available CPUs, which seemed
deliberate. Like maybe to allow running two branches simultaneously
(that doesn't necessarily work well with ccache, though).
On Sat, Nov 19, 2022 at 01:35:17PM -0800, Andres Freund wrote:
> The limit for cirrus is 16 linux CPUs though, not 8.
Oh. Then I don't see any issue.
> We'll temporarily go up to 12 due to CompilerWarnings after the change.
What do you mean "temporarily" ? I think you're implying that the
Warnings task is fast but (at least right now) it is not.
Note that the most recent "code coverage" task is built into the
linux-autoconf task, and slows it down some more. That's because it's
the only remaining in-tree build, and I aimed to only show coverage for
changed files (I know you questioned whether that was okay, but to me it
still seems to be valuable, even though it obviously doesn't show
changes outside of those files). And I couldn't see how to map from
"object filename to source file" with meson, although I guess it's
possible with instrospection. I haven't re-sent that patch because it's
waiting on cfbot changes.
--
Justin
