unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: bo0od <bo0od@riseup.net>, 47717@debbugs.gnu.org
Subject: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
Date: Tue, 20 Apr 2021 21:35:34 -0400	[thread overview]
Message-ID: <871rb4fmhl.fsf@gmail.com> (raw)
In-Reply-To: <878s5jiann.fsf@netris.org> (Mark H. Weaver's message of "Thu, 15 Apr 2021 15:56:33 -0400")

Hi,

Mark H Weaver <mhw@netris.org> writes:

> bo0od <bo0od@riseup.net> writes:
>
>>  > I mean the ‘outrageously’ part.  When Linux runs out of memory, it
>>  > freezes up.  Moral judgment is futile.  Better to adopt raingloom's
>>  > earlyoom suggestion or similar.
>>
>> Im using default guix system nothing special, If this package usable to
>> solve these stuff i suggest then to include it by default.
>
> 'earlyoom' behavior is not necessarily desirable.  I, for one, have a
> fairly old computer by today's standards, and sometimes I ask it to do
> intensive things that are at the edge of its capabilities, such as
> compiling GNU IceCat.  An aggressive 'earlyoom' might prematurely abort
> jobs that could have completed, and thereby make it impossible for me to
> continue using this old computer for development.
>
> With that in mind, it's far from clear that 'earlyoom' should be our
> default behavior.  It's good to have it as an option, though.

Earlyoom's default config is to only kills processes when both the
physical memory *and* the swap have been used by more than 90%; in such
as serious resource depletion situation, that usually mean having to
hard reset the machine, or waiting one night not knowing if it'll be
done doing whatever it's doing the next morning (probably getting OOM'd
anyway by the kernel, Linux).

>>  > 4 GiB is absolutely not enough to build an outrageous amount of ‘modern’
>>  > software, especially in parallel (so not using --cores=1 --max-jobs=1)
>>  > to make use of those expensive cores.
>>  >
>>  > I'm disgusted too.
>>
>> Yes it is, But you know this cant be a way of life with guix for end
>> user no? Something by default should solve this matter otherwise this is
>> not usable distro.
>
> Many people are happily using it, and are quite enthusiastic about it,
> so evidently it's "usable".  That doesn't imply that it's good for
> everyone.  Perhaps you would prefer a more traditional distro, or one
> that has had more time to mature.  If so, that's okay.

My 2 cents here is that earlyoom makes Guix System more usable on dated
hardware than Linux's default OOM behavior; from my experience of using
it on a 4 GiB RAM 2010-era laptop for a good while.

I personally would see it a good option for our users to have it on by
default *if* we could manage to connect Earlyoom's notification system
with the desktop (via D-Bus, I think it supports that), so that when a
process is killed, the users has some feedback about it (the stock Linux
OOMK is sure to not let you wondering what's going on -- everything
stops to a crawl, and your hard drive gets thrashed).

Maxim




  parent reply	other threads:[~2021-04-21  1:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12  5:39 bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure bo0od
2021-04-12 18:04 ` bug#47717: guix becomes unresponsive while building the 'vigra' package Leo Famulari
2021-04-13 11:03   ` bo0od
2021-04-13 17:35     ` Leo Famulari
2021-04-14 16:06       ` bo0od
2021-04-14  8:21     ` Mark H Weaver
2021-04-14 17:08       ` bo0od
2021-04-12 18:41 ` bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure Tobias Geerinckx-Rice via Bug reports for GNU Guix
2021-04-12 22:59   ` raingloom
2021-04-13 11:34   ` bo0od
2021-04-14  0:40     ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2021-04-14 16:54       ` bo0od
2021-04-15 19:56         ` Mark H Weaver
2021-04-16  3:08           ` bo0od
2021-04-21  1:35           ` Maxim Cournoyer [this message]
2021-04-22 18:34             ` Mark H Weaver
2021-04-25  8:14               ` Efraim Flashner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871rb4fmhl.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=47717@debbugs.gnu.org \
    --cc=bo0od@riseup.net \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).