Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM
On 6/3/15 10:56 PM, Mike Gilbert wrote: > The chromium build issue is a point of some contention; see the bug below. > > https://bugs.gentoo.org/show_bug.cgi?id=471810 > > I agree that it makes sense to check virtual memory. I guess that > would be MemTotal + SwapTotal in /proc/meminfo. > > It would also probably make more sense to check available memory > (MemAvailable + SwapFree). Maybe that should be implemented in a new > function, like check-reqs_memory_available. Agreed. I think one of the issues is that the eclass aims to support multiple kernels, not just Linux. It's not obvious how to implement such check portably for non-Linux systems. Maybe we could keep it just Linux-only. I'm totally open to suggestions from the community. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM
On Wed, 3 Jun 2015 21:32:34 +0100 Ciaran McCreesh wrote: > > Swap is horrifically slow. It's better to fail than to use swap for > stuff... > Is it better to fail when you have already lost several hours in compilations? Or is it better to use some additional parallel swap on a bunch of HDDs or SDDs to FINISH emerge during 30 minutes more? I think the latter is better than fail for no reason. BTW, RAM + swap is better than swap only.
Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM
On Wed, Jun 3, 2015 at 4:22 PM, Christian Bricart wrote:
> Dear devs,
>
> i've just hit the constraint CHECKREQS_MEMORY=3G in
>>=www-client/chromium-44.* on a 2 GiB RAM machine.. (having additionally
> 5G Swap on SSD..)
>
> I personally doubt that check-reqs_memory() in the eclass should only
> check for *physical* rather than *virtual* RAM to fulfill this
> constraint and fail if unsatisfied.
>
> So my proposal would rather be:
>
> * $CHECKREQS_MEMORY<=pysical RAM -> ok
> * $CHECKREQS_MEMORY>pysical RAM && <= virtual RAM -> ewarn
> * $CHECKREQS_MEMORY>virtual RAM -> eerror (may still be overridden by
> ${I_KNOW_WHAT_I_AM_DOING} in check-reqs_output() )
>
> what do you think?
>
The chromium build issue is a point of some contention; see the bug below.
https://bugs.gentoo.org/show_bug.cgi?id=471810
I agree that it makes sense to check virtual memory. I guess that
would be MemTotal + SwapTotal in /proc/meminfo.
It would also probably make more sense to check available memory
(MemAvailable + SwapFree). Maybe that should be implemented in a new
function, like check-reqs_memory_available.
I don't like your weird ewarn/eerror proposal. We should either fail,
or not fail in check-reqs_pkg_pretend and check-reqs_pkg_setup. And
the helper functions should continue to return a non-zero status on
failure.
Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM
Dnia 2015-06-03, o godz. 22:39:10 Christian Bricart napisał(a): > Am 03.06.2015 um 22:32 schrieb Ciaran McCreesh: > > On Wed, 03 Jun 2015 22:22:39 +0200 > >> i've just hit the constraint CHECKREQS_MEMORY=3G in > >>> =www-client/chromium-44.* on a 2 GiB RAM machine.. (having > >>> additionally > >> 5G Swap on SSD..) > >> > >> I personally doubt that check-reqs_memory() in the eclass should only > >> check for *physical* rather than *virtual* RAM to fulfill this > >> constraint and fail if unsatisfied. > > > > Swap is horrifically slow. It's better to fail than to use swap for > > stuff... > > > (basically) agreed - but in distcc/icecream/whatever builds, linking > *may* also be done on remote machines, which *may* fulfill the memory > constraint.. Nay, linking is always done locally. And even if you were right, this isn't a lottery. It ain't 'let's let user dumbly waste 4 hours, maybe it will link for him this time'. -- Best regards, Michał Górny pgpCyzBrXLMPx.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM
Am 03.06.2015 um 22:32 schrieb Ciaran McCreesh: > On Wed, 03 Jun 2015 22:22:39 +0200 >> i've just hit the constraint CHECKREQS_MEMORY=3G in >>> =www-client/chromium-44.* on a 2 GiB RAM machine.. (having >>> additionally >> 5G Swap on SSD..) >> >> I personally doubt that check-reqs_memory() in the eclass should only >> check for *physical* rather than *virtual* RAM to fulfill this >> constraint and fail if unsatisfied. > > Swap is horrifically slow. It's better to fail than to use swap for > stuff... > (basically) agreed - but in distcc/icecream/whatever builds, linking *may* also be done on remote machines, which *may* fulfill the memory constraint.. we're talking about *build* constraints rather than *run* constraints, right..? Christian signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM
On Wed, 03 Jun 2015 22:22:39 +0200 > i've just hit the constraint CHECKREQS_MEMORY=3G in > >=www-client/chromium-44.* on a 2 GiB RAM machine.. (having > >additionally > 5G Swap on SSD..) > > I personally doubt that check-reqs_memory() in the eclass should only > check for *physical* rather than *virtual* RAM to fulfill this > constraint and fail if unsatisfied. Swap is horrifically slow. It's better to fail than to use swap for stuff... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM
Dear devs,
i've just hit the constraint CHECKREQS_MEMORY=3G in
>=www-client/chromium-44.* on a 2 GiB RAM machine.. (having additionally
5G Swap on SSD..)
I personally doubt that check-reqs_memory() in the eclass should only
check for *physical* rather than *virtual* RAM to fulfill this
constraint and fail if unsatisfied.
So my proposal would rather be:
* $CHECKREQS_MEMORY<=pysical RAM -> ok
* $CHECKREQS_MEMORY>pysical RAM && <= virtual RAM -> ewarn
* $CHECKREQS_MEMORY>virtual RAM -> eerror (may still be overridden by
${I_KNOW_WHAT_I_AM_DOING} in check-reqs_output() )
what do you think?
cheers
Christian
