all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: bo0od <bo0od@riseup.net>, 47717@debbugs.gnu.org
Subject: bug#47717: guix outrageously exhaust itself (freeze) when there is package build failure
Date: Thu, 22 Apr 2021 14:34:22 -0400	[thread overview]
Message-ID: <87k0ouyxpy.fsf@netris.org> (raw)
In-Reply-To: <871rb4fmhl.fsf@gmail.com>

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> '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).
[...]
> 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.

Okay, I trust your judgment on this.  I haven't tried 'earlyoom' myself.
Moreover, my use case is very unusual, and so it doesn't make sense to
choose a default behavior based on my needs.

So, I've changed my mind.  Thanks for talking me through it.

> 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).

That sounds excellent, if it can be done.  Otherwise, it might still
make sense to have 'earlyoom' on by default in Guix.  I'll leave it to
others to decide.

      Thanks,
        Mark

-- 
Support Richard Stallman against the vicious misinformation campaign
against him and the FSF.  See <https://stallmansupport.org> for more.




  reply	other threads:[~2021-04-22 18:37 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
2021-04-22 18:34             ` Mark H Weaver [this message]
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

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

  git send-email \
    --in-reply-to=87k0ouyxpy.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=47717@debbugs.gnu.org \
    --cc=bo0od@riseup.net \
    --cc=maxim.cournoyer@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.