On Tue, Jun 29, 2021 at 04:25:13PM -0400, Ben Cotton wrote:
>
https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros
>
> == Summary ==
> Introduce macros, similar to openSUSE's
> [
https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
> memory-constraints]), for optionally limiting build parallelism for
> build-time memory-bound packages
>
> == Owner ==
> * Name: [[User:salimma|Michel Alexandre Salim]]
> * Email: michel AT michel-slm DOT name
>
>
> == Detailed Description ==
> Some source packages have a memory usage per build thread higher than
> the RAM:CPU ratio available in some of our builders. Further, this
> ratio can be different for different build server on different
> architectures.
>
> At the moment, such packages
>
([
https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a...
> ceph],
[
https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367d...
> chromium],
[
https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b0...
> mcrouter]) have to implement their own logic for determining the safe
> amount of parallelism, and redefine `_smp_build_ncpus`.
>
> When this proposal is implemented, they can instead declaratively
> specify the amount of RAM needed per build thread, e.g.
>
> %limit_build -m 8192
>
> for declaring a build thread should be allocated 8GB of RAM.
>
> Since Koji supports
> [
https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-cha...
> setting default values for macros], there will be a macro for the
> default memory limit (name TBD) that, if set, will be used to cap
> `_smp_build_ncpus` unless overridden by `%limit_build -m`.
Is the default required? Wouldn't it be enough to make '%limit_build -m
8192'
*lower* _smp_build_ncpus if it detects that not enough memory is present?
I.e. keep status quo by default, optionally lower (and only lower) _smp_build_ncpus
when '%limit_build -m …' is used?
That was meant to be optional -- and if it's not set, the status quo is
kept anyway. I'll revise the documentation.
Best regards,
--
Michel Alexandre Salim
profile: