Dne 04. 08. 20 v 21:38 Michael Catanzaro napsal(a):
> On Tue, Aug 4, 2020 at 10:31 am, Chris Murphy
> wrote:
>> Should we go back to the old workaround for F33? Madness for one more
>> release? And then drop the madness once there's a dnf solution?
>
> We could, but we have installed so many
Dne 04. 08. 20 v 20:58 Vitaly Zaitsev via devel napsal(a):
> On 04.08.2020 16:45, Vít Ondruch wrote:
>> I think the "don't use autoremove" is better suggestion ATM, because I
>> don't really want to keep earlyoom on the system in case there is
>> systemd-oomd or whatever should be the successor.
On Tuesday, August 4, 2020 1:45:52 AM MST Vít Ondruch wrote:
> Yesterday, I have updated my Rawhide and wondered why `dnf autoremove`
> would want to remove earlyoom just to discover that soft dependency in
> earlyoom was dropped [1] and hence nothing requires earlyoom and DNF is
> free to remove
On Tue, Aug 4, 2020 at 10:31 am, Chris Murphy
wrote:
Should we go back to the old workaround for F33? Madness for one more
release? And then drop the madness once there's a dnf solution?
We could, but we have installed so many other things that it's becoming
quite hard to keep track of them
On 04.08.2020 16:45, Vít Ondruch wrote:
> I think the "don't use autoremove" is better suggestion ATM, because I
> don't really want to keep earlyoom on the system in case there is
> systemd-oomd or whatever should be the successor.
You can always easily swap one package to another:
sudo dnf
On Tue, Aug 4, 2020 at 8:46 AM Vít Ondruch wrote:
>
>
> Dne 04. 08. 20 v 16:05 Vitaly Zaitsev via devel napsal(a):
> > On 04.08.2020 15:48, Michael Catanzaro wrote:
> >> In the meantime, if you want to keep earlyoom, don't use autoremove.
> > sudo dnf mark install earlyoom
> >
>
> I think the
On Tue, Aug 4, 2020 at 7:49 AM Michael Catanzaro wrote:
> In the meantime, it will get
> pulled in on upgrades to F32 due to the old workaround, but it's not
> currently being pulled in on upgrades to F33.
Should we go back to the old workaround for F33? Madness for one more
release? And then
Dne 04. 08. 20 v 16:05 Vitaly Zaitsev via devel napsal(a):
> On 04.08.2020 15:48, Michael Catanzaro wrote:
>> In the meantime, if you want to keep earlyoom, don't use autoremove.
> sudo dnf mark install earlyoom
>
I think the "don't use autoremove" is better suggestion ATM, because I
don't
On 04.08.2020 15:48, Michael Catanzaro wrote:
> In the meantime, if you want to keep earlyoom, don't use autoremove.
sudo dnf mark install earlyoom
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
On Tue, Aug 4, 2020 at 10:45 am, Vít Ondruch
wrote:
Yesterday, I have updated my Rawhide and wondered why `dnf autoremove`
would want to remove earlyoom just to discover that soft dependency in
earlyoom was dropped [1] and hence nothing requires earlyoom and DNF
is
free to remove this
Yesterday, I have updated my Rawhide and wondered why `dnf autoremove`
would want to remove earlyoom just to discover that soft dependency in
earlyoom was dropped [1] and hence nothing requires earlyoom and DNF is
free to remove this package (and it is possibly not installed anymore on
upgraded
On Wed, Jan 15, 2020 at 6:40 PM John M. Harris Jr wrote:
>
> On Wednesday, January 8, 2020 12:24:23 PM MST Chris Murphy wrote:
> > Looks like PSI based oom killing doesn't work without swap. Therefore
> > oomd can't be considered a universal solution. Quite a lot of
> > developers have
On Wednesday, January 8, 2020 12:24:23 PM MST Chris Murphy wrote:
> Looks like PSI based oom killing doesn't work without swap. Therefore
> oomd can't be considered a universal solution. Quite a lot of
> developers have workstations with quite a decent amount of RAM,
> ~64GiB, and do not use swap
On Fri, Jan 10, 2020 at 2:05 AM Lennart Poettering wrote:
>
> On Mi, 08.01.20 12:24, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering
> > wrote:
> > >
> > > - facebook is working on making oomd something that just works for
> > > everyone,
On-going related discussions on linux-mm@ list
user space unresponsive, followup: lsf/mm congestion
https://marc.info/?t=15784291223=1=2
Gist here is the kernel is working as expected. The process is asking
for resources that don't exist and the kernel can't really assume
either the workload
On Wed, Jan 8, 2020 at 8:25 PM Chris Murphy wrote:
>
> On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering
> wrote:
> >
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so that it can
On Mi, 08.01.20 12:24, Chris Murphy (li...@colorremedies.com) wrote:
> On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering
> wrote:
> >
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so
On Thu, Jan 9, 2020 at 5:58 AM Benjamin Berg wrote:
>
> On Wed, 2020-01-08 at 12:24 -0700, Chris Murphy wrote:
> > On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering
> > wrote:
> > > - facebook is working on making oomd something that just works for
> > > everyone, they are in the final
On Wed, 2020-01-08 at 12:24 -0700, Chris Murphy wrote:
> On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering
> wrote:
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so that it can just
On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering wrote:
>
> - facebook is working on making oomd something that just works for
> everyone, they are in the final rounds of canonicalizing the
> configuration so that it can just work for all workloads without
> tuning. The last bits for this
On Tue, Jan 7, 2020 at 1:48 PM Mark Otaris wrote:
>
> I intended to demonstrate that cgroups can be used to cause the kernel OOM
> killer to react appropriately and fast enough, implying that replacing the
> OOM killer is not necessary and that replacing it by a userspace OOM killer
> that does
I intended to demonstrate that cgroups can be used to cause the kernel OOM
killer to react appropriately and fast enough, implying that replacing the
OOM killer is not necessary and that replacing it by a userspace OOM killer
that does not account for cgroups can be undesirable. The exact same
On Tue, Jan 07, 2020 at 09:19:47AM -0600, Michael Catanzaro wrote:
> On Tue, Jan 7, 2020 at 5:27 am, Mark Otaris wrote:
> >Try it. With a memory limit,
> >
> >podman run --rm -it --memory=1G fedora bash -c 'dnf install -y
> >stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm
> >100'
On Di, 07.01.20 09:27, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> wrote:
> > - oomd currently polls some parameters in time intervals too,
> > still. They are working on getting rid of that too, so that
> > everything is event based
On Tue, Jan 7, 2020 at 8:55 AM Chris Murphy wrote:
>
> On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris wrote:
> >
> > > For now, kernel developers have made it clear they do not care about
> > > user space responsiveness. At all. Their concern with kernel
> > > oom-killer is strictly with keeping
On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris wrote:
>
> > For now, kernel developers have made it clear they do not care about
> > user space responsiveness. At all. Their concern with kernel
> > oom-killer is strictly with keeping the kernel functioning.
>
> This is false. The stated purpose of
On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
wrote:
- oomd currently polls some parameters in time intervals too,
still. They are working on getting rid of that too, so that
everything is event based via PSI. Given their own focus on servers
it's not a primary goal, but still a
On Tue, Jan 7, 2020 at 5:27 am, Mark Otaris wrote:
Try it. With a memory limit,
podman run --rm -it --memory=1G fedora bash -c 'dnf install -y
stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100'
will use CPU but keep your system responsive. Without the memory limit
(this
On Tue, Jan 7, 2020 at 11:23 am, Kamil Paral wrote:
In your example you forget that swap needs to filled almost to full
for early-oom to start reacting. That takes time during which the
system responsibility is abysmal. The UX difference happens only
after you've already suffered through a
On Tue, Jan 7, 2020 at 10:09 am, Benjamin Berg
wrote:
Even if that is the case, on F31 (with GNOME 3.34.2) we do place most
user processes into separate scopes[1]. This is not perfect, because
it
currently only affects processes launched by gnome-shell, gnome-
settings-daemon and
On Sat, 2020-01-04 at 12:17 -0600, Michael Catanzaro wrote:
> On Sat, Jan 4, 2020 at 11:38 am, Zbigniew Jędrzejewski-Szmek
> wrote:
> > What about using the memory controller for user units to allocate
> > memory resources between the processes in the user session? Thanks
> > to
> > recent
On Tue, 2020-01-07 at 11:28 +0100, Lennart Poettering wrote:
> On Mo, 06.01.20 14:53, Michael Catanzaro (mcatanz...@gnome.org) wrote:
>
> > On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> > wrote:
> > > - facebook is working on making oomd something that just works for
> > > everyone,
Hi,
[resend this older message for the list]
On Mon, 2020-01-06 at 14:53 -0600, Michael Catanzaro wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> wrote:
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of
On Tue, 2020-01-07 at 11:44 +0100, Benjamin Berg wrote:
> On Tue, 2020-01-07 at 10:21 +, Zbigniew Jędrzejewski-Szmek wrote:
> > I'm quoting from my mail from this same thread:
> >
> > │ ├─gnome-shell-wayland.service
> > │ │ ├─1501571 /usr/bin/gnome-shell
> > │ │ ├─1501606 /usr/bin/Xwayland :0
On Tue, 2020-01-07 at 10:21 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jan 07, 2020 at 11:07:49AM +0100, Benjamin Berg wrote:
> > On Tue, 2020-01-07 at 09:47 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > I wanted to ask about this too... but didn't know where ;)
> > > As of today,
On 1/7/20 11:07 AM, Benjamin Berg wrote:
> On Tue, 2020-01-07 at 09:47 +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Mon, Jan 06, 2020 at 02:53:13PM -0600, Michael Catanzaro wrote:
>>> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
>>> wrote:
- facebook is working on making oomd
On Mo, 06.01.20 14:53, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> wrote:
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so
On Mon, Jan 6, 2020 at 8:52 PM Roberto Ragusa wrote:
> On 2020-01-06 18:31, Kamil Paral wrote:
>
> > FWIW, the behavior on Android is very close to what is proposed here. If
> your application exceeds the amount of available memory, it simply closes
> right in front of your eyes. No explanation,
On Tue, Jan 7, 2020 at 8:09 AM Aleksandra Fedorova
wrote:
> UX before: system works, I run heavy application, system starts to hang, i
> understand that there is an issue, i can kill the app or reboot, which
> gives me clean and working system.
>
> UX after: system works, no visible problems.
On Tue, Jan 07, 2020 at 11:07:49AM +0100, Benjamin Berg wrote:
> On Tue, 2020-01-07 at 09:47 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Jan 06, 2020 at 02:53:13PM -0600, Michael Catanzaro wrote:
> > > On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> > > wrote:
> > > > - facebook is
On Tue, 2020-01-07 at 09:47 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 06, 2020 at 02:53:13PM -0600, Michael Catanzaro wrote:
> > On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> > wrote:
> > > - facebook is working on making oomd something that just works for
> > > everyone,
On Tue, Jan 07, 2020 at 08:57:04AM +0200, Damian Ivanov wrote:
> I am not using a swap partition at all, the system always hangs when
> OOM but sometimes also at just less than 20%
This might be https://gitlab.gnome.org/GNOME/gnome-shell/issues/1981
or one of the duplicates.
Zbyszek
On Mon, Jan 06, 2020 at 02:53:13PM -0600, Michael Catanzaro wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
> wrote:
> >- facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so that it
Chris Murphy wrote:
> It's not correct that the Workstation working group doesn't want to
> see it supported, it's a question of whether and to what degree it can
> be supported, and making sure users have expectations proper set. I
> wouldn't want users thinking it'll work by advertising that it
On Tue, Jan 7, 2020 at 12:08 AM Aleksandra Fedorova wrote:
>
>
>
> On Mon, 6 Jan 2020, 18:32 Kamil Paral, wrote:
>>
>> On Sun, Jan 5, 2020 at 12:43 PM Aleksandra Fedorova
>> wrote:
>>>
>>> I wonder, how I as a user going to be informed about the
>>> earlyoom-event? I assume abrt will recognize
On Mon, 6 Jan 2020, 18:32 Kamil Paral, wrote:
> On Sun, Jan 5, 2020 at 12:43 PM Aleksandra Fedorova
> wrote:
>
>> I wonder, how I as a user going to be informed about the
>> earlyoom-event? I assume abrt will recognize the crash? Will it be
>> easily visible from the abrt report that it was the
I am not using a swap partition at all, the system always hangs when
OOM but sometimes also at just less than 20%
On Tue, Jan 7, 2020 at 8:43 AM Peter Hutterer wrote:
>
> On Sat, Jan 04, 2020 at 12:15:20PM -0600, Michael Catanzaro wrote:
> > Let's keep this desktop-focused, since the proposal
On Sat, Jan 04, 2020 at 12:15:20PM -0600, Michael Catanzaro wrote:
> Let's keep this desktop-focused, since the proposal does not affect Server
> edition.
>
> On Sat, Jan 4, 2020 at 12:48 pm, drago01 wrote:
> > As for the desktop case the running web browers in a cgroup to keep them
> > in check
> For now, kernel developers have made it clear they do not care about
> user space responsiveness. At all. Their concern with kernel
> oom-killer is strictly with keeping the kernel functioning.
This is false. The stated purpose of the OOM killer is not only to keep the
kernel alive. Nor does
Seems like this bug:
**Kills multiple processes at once**
https://github.com/rfjakob/earlyoom/issues/121
but according to github it's fixed now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering
wrote:
- facebook is working on making oomd something that just works for
everyone, they are in the final rounds of canonicalizing the
configuration so that it can just work for all workloads without
tuning. The last bits for this to be
On Mon, Jan 6, 2020 at 1:14 PM Robbie Harwood wrote:
>
> Chris Murphy writes:
> > As for swap size options including no swap, and maybe swap-on-ZRAM:
> > https://pagure.io/fedora-workstation/issue/120
> > https://bugzilla.redhat.com/show_bug.cgi?id=1731978
> >
> > There are all kinds of useful
Chris Murphy writes:
> Robbie Harwood wrote:
>> "John M. Harris Jr" writes:
>>> On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote:
Robbie Harwood writes:
> Ben Cotton writes:
>
>> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>>
>> == Summary ==
On Mon, Jan 6, 2020 at 12:11 PM Robbie Harwood wrote:
>
> "John M. Harris Jr" writes:
>
> > On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote:
> >> Robbie Harwood writes:
> >>> Ben Cotton writes:
> >>>
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> ==
On 2020-01-06 18:31, Kamil Paral wrote:
FWIW, the behavior on Android is very close to what is proposed here. If your
application exceeds the amount of available memory, it simply closes right in
front of your eyes. No explanation, nothing, it's just gone (might be different
on latest
On Mon, Jan 6, 2020 at 11:53 am, Chris Murphy
wrote:
And yes the idea is to go a little faster. Earlyoom is easy to take
out. And I have no problem with it coming out in fc33 if oomd or (more
likely) lmm are ready by then.
Brainstorming: if a systemd-level solution were to be ready in the F33
"John M. Harris Jr" writes:
> On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote:
>> Robbie Harwood writes:
>>> Ben Cotton writes:
>>>
https://fedoraproject.org/wiki/Changes/EnableEarlyoom
== Summary ==
Install earlyoom package, and enable it by default. This
On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering wrote:
>
> On Mo, 06.01.20 11:22, Michael Catanzaro (mcatanz...@gnome.org) wrote:
>
> So I talked to Tejun Heo about this (kernel cgroups maintainer,
> working for facebook with the people who did the PSI stuff, kernel mm
> guy). Here's the gist:
On Mon, Jan 6, 2020 at 7:10 PM Lennart Poettering
wrote:
> - going down to 100ms poll intervals is a bad idea, 1s is sufficient,
> maybe higher.
>
According to the project readme, the query interval is 100ms only if the
lack or free RAM starts to get severe. Otherwise the interval is claimed
On Mo, 06.01.20 11:22, Michael Catanzaro (mcatanz...@gnome.org) wrote:
So I talked to Tejun Heo about this (kernel cgroups maintainer,
working for facebook with the people who did the PSI stuff, kernel mm
guy). Here's the gist:
- earlyoom might be OK as short time stopgap if people really want
On Fri, Jan 3, 2020 at 8:20 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off.
On Sun, Jan 5, 2020 at 12:43 PM Aleksandra Fedorova
wrote:
> I wonder, how I as a user going to be informed about the
> earlyoom-event? I assume abrt will recognize the crash? Will it be
> easily visible from the abrt report that it was the OOM?
>
> The concern is: if we enable such a service,
On Mon, Jan 6, 2020 at 5:47 pm, Lennart Poettering
wrote:
Yes, l-m-m is great. If we can deploy l-m-m today already, why isn't
it good enoug for earlyoom?
GMemoryMonitor is the GLib API that's implemented using
low-memory-monitor's D-Bus API.
In practice, using it for OOM killing is not
On Mo, 06.01.20 10:09, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> Is there a way to check memory usage without periodic wakeups?
PSI. It measures latency though. Which is the right thing to measure
here... You can configure thresholds there and it wakes you up when
those are hit. Thus
On Mo, 06.01.20 17:47, Lennart Poettering (mzerq...@0pointer.de) wrote:
> On Mo, 06.01.20 08:51, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Mon, Jan 6, 2020 at 3:08 AM Lennart Poettering
> > wrote:
> > >>
> > > Looking at the sources very superficially I see a couple of problems:
>
On Mo, 06.01.20 08:51, Chris Murphy (li...@colorremedies.com) wrote:
> On Mon, Jan 6, 2020 at 3:08 AM Lennart Poettering
> wrote:
> >>
> > Looking at the sources very superficially I see a couple of problems:
> >
> > 1. Waking up all the time in 100ms intervals? We generally try to
> >avoid
On Mon, Jan 6, 2020 at 11:07 am, Lennart Poettering
wrote:
Hmm, are we sure this is something we want to have in the default
install? Is the code really good enough for that?
Looking at the sources very superficially I see a couple of problems:
1. Waking up all the time in 100ms intervals?
On Mon, Jan 6, 2020 at 4:57 AM Roberto Ragusa wrote:
>
> On 1/5/20 12:38 AM, Chris Murphy wrote:
> > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova
> > wrote:
> >
> >> Since in the Change we are not introducing just the earlyoom tool but
> >> enable it with a specific profile I would add
On Mon, Jan 6, 2020 at 3:08 AM Lennart Poettering wrote:
>>
> Looking at the sources very superficially I see a couple of problems:
>
> 1. Waking up all the time in 100ms intervals? We generally try to
>avoid waking the CPU up all the time if nothing happens. Saving
>power and things.
I
On Mon, Jan 6, 2020 at 5:08 AM Lennart Poettering
wrote:
>
> I mean, yes, the OOM killer might not be that great currently, but
> this sounds like something to fix in kernel land, and if that doesn't
> work out for some reason because kernel devs can't agree, then do it
> as fallback in
On 1/5/20 12:38 AM, Chris Murphy wrote:
On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova wrote:
Since in the Change we are not introducing just the earlyoom tool but enable it
with a specific profile I would add those details here. Smth like:
"earlyoom service will choose the offending
On Fr, 03.01.20 14:18, Ben Cotton (bcot...@redhat.com) wrote:
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to
On Sun, Jan 5, 2020 at 4:43 AM Aleksandra Fedorova wrote:
>
> I wonder, how I as a user going to be informed about the
> earlyoom-event?
Same as a kernel oom-killer event. Primary source is the journal.
But well before either earlyoom sends SIGTERM or kernel oom-killer
kills something, the user
On Sun, Jan 5, 2020 at 2:18 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> > My understanding of systemd OOMPolicy= behavior, is it looks for the
> > kernel's oom-killer messages and acts upon those. Whereas earlyoom
> > uses the same
On Sun, Jan 05, 2020 at 12:29:40PM +0100, Aleksandra Fedorova wrote:
> On Sun, Jan 5, 2020 at 10:18 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> > > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova
> > > wrote:
> > >
> > > >
On Sun, Jan 5, 2020 at 12:39 AM Chris Murphy wrote:
>
> On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova wrote:
>
> > Since in the Change we are not introducing just the earlyoom tool but
> > enable it with a specific profile I would add those details here. Smth like:
> >
> > "earlyoom
On Sun, Jan 5, 2020 at 10:18 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova
> > wrote:
> >
> > > Since in the Change we are not introducing just the earlyoom tool but
> > > enable it
On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova wrote:
>
> > Since in the Change we are not introducing just the earlyoom tool but
> > enable it with a specific profile I would add those details here. Smth like:
> >
> >
Michael Catanzaro wrote:
> nohang has experimented with PSI, but it actually isn't using PSI
> metrics by default because they've proven to be less effective than
> hoped for. In theory, using an interactivity measure like PSI should
> provide for the best results, but in practice it just hasn't
John M. Harris Jr wrote:
> This is simply not the case. It may be for GNOME, but I haven't tested
> that. It definitely is not the case for Plasma.
… unless you want to run KMail/Akonadi on it. :-)
But yes, Plasma itself works fine with 2 GiB (I haven't actually tested with
less than 4 GiB, but
On Saturday, January 4, 2020 2:29:11 PM MST drago01 wrote:
> A modern desktop with apps on top will not run well enough on 2GB,
> lets stop pretending it does.
This is simply not the case. It may be for GNOME, but I haven't tested that.
It definitely is not the case for Plasma.
--
John M.
On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova wrote:
> Since in the Change we are not introducing just the earlyoom tool but enable
> it with a specific profile I would add those details here. Smth like:
>
> "earlyoom service will choose the offending process based on the same
> oom_score
On Sat, Jan 4, 2020 at 2:30 PM drago01 wrote:
>
> On Sat, Jan 4, 2020 at 7:32 PM Chris Murphy wrote:
> >
> > It might be. And it might need to be tweaked. Perhaps 6% for SIGTERM
> > and 3% for SIGKILL. Or even 5% and 2.5%. For sure using a percentage
> > of RAM and swap is too simplistic. But
On Sat, Jan 4, 2020 at 7:32 PM Chris Murphy wrote:
>
> On Sat, Jan 4, 2020 at 4:48 AM drago01 wrote:
> >
> >
> >
> > On Saturday, January 4, 2020, Neal Gompa wrote:
> >>
> >> On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel
> >> wrote:
> >> >
> >> > On 03.01.2020 22:27, Neal Gompa
On Sat, Jan 4, 2020 at 11:20 AM John M. Harris Jr wrote:
>
> On Saturday, January 4, 2020 11:16:24 AM MST Michael Catanzaro wrote:
> > On Fri, Jan 3, 2020 at 5:52 pm, John M. Harris Jr
> > wrote:
> >
> > > In that case, I'd suggest waiting the 15 minutes, and then not
> > > bogging down
> > >
On Saturday, January 4, 2020 11:31:49 AM MST Chris Murphy wrote:
> A modern operating system needs to
> know better than to allow unprivileged processes to take down the
> whole system.
Well, you can configure quotas if you really want, but the idea is that it's
YOUR COMPUTER, and you should be
On Sat, Jan 4, 2020 at 4:48 AM drago01 wrote:
>
>
>
> On Saturday, January 4, 2020, Neal Gompa wrote:
>>
>> On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel
>> wrote:
>> >
>> > On 03.01.2020 22:27, Neal Gompa wrote:
>> > > and servers...
>> >
>> > Admins will be very happy when such
On Saturday, January 4, 2020 4:48:04 AM MST drago01 wrote:
> And btw we should really update the minimum memory requirements in our
> documentation, the current ones have nothing to do with reality (if you
> want a pleasant user experience).
That is not necessary, at all. I'm running Fedora on a
On Saturday, January 4, 2020 11:16:24 AM MST Michael Catanzaro wrote:
> On Fri, Jan 3, 2020 at 5:52 pm, John M. Harris Jr
> wrote:
>
> > In that case, I'd suggest waiting the 15 minutes, and then not
> > bogging down
> > your system that badly the next time. This is, really, the best
> >
On Sat, Jan 4, 2020 at 12:45 AM wrote:
>
> В Суб, 04/01/2020 в 08:27 +0100, Vitaly Zaitsev via devel пишет:
>
> > I'm strongly against adding of any user-space OOM killers to Fedora
> > default images. Users should explicitly enable them only when needed.
>
> Just my 2 cents: i tested early
On Friday, January 3, 2020 11:34:13 PM MST Andreas Tunek wrote:
> Den lör 4 jan. 2020 kl 01:53 skrev John M. Harris Jr :
> > On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote:
> > > in the cases were I could issue syrq+b, responsiveness was so bad
> > > it'd take upwards of 15 minutes
On Sat, Jan 4, 2020 at 11:38 am, Zbigniew Jędrzejewski-Szmek
wrote:
What about using the memory controller for user units to allocate
memory resources between the processes in the user session? Thanks to
recent developments, the gnome session uses separate systemd units
(and thus separate
On Fri, Jan 3, 2020 at 5:52 pm, John M. Harris Jr
wrote:
In that case, I'd suggest waiting the 15 minutes, and then not
bogging down
your system that badly the next time. This is, really, the best
option.
I'm going to suggest you stop replying in this thread if you're not
interested in
On Fri, Jan 3, 2020 at 11:12 pm, Tom Seewald wrote:
I think this would be a really big improvement for workstation and
other desktop spins, the handling of out of memory situations have
been a consistent paint point on Linux. However, may I ask why
EarlyOOM was chosen over something like
Let's keep this desktop-focused, since the proposal does not affect
Server edition.
On Sat, Jan 4, 2020 at 12:48 pm, drago01 wrote:
As for the desktop case the running web browers in a cgroup to keep
them in check would solve most real world problems - other common
desktop apps don't use
On Saturday, January 4, 2020, Neal Gompa wrote:
> On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 03.01.2020 22:27, Neal Gompa wrote:
> > > and servers...
> >
> > Admins will be very happy when such user-space killer will kill for
> > example PgSQL database server
On Fri, Jan 03, 2020 at 02:18:40PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to
On Sat, Jan 4, 2020 at 2:33 AM Vitaly Zaitsev via devel
wrote:
>
> On 03.01.2020 22:27, Neal Gompa wrote:
> > and servers...
>
> Admins will be very happy when such user-space killer will kill for
> example PgSQL database server and cause DB corruption or loss of banking
> transactions.
>
This
On Fri, 3 Jan 2020, 20:19 Ben Cotton, wrote:
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. The
В Суб, 04/01/2020 в 08:27 +0100, Vitaly Zaitsev via devel пишет:
> I'm strongly against adding of any user-space OOM killers to Fedora
> default images. Users should explicitly enable them only when needed.
Just my 2 cents: i tested early versions of earlyoom and have weird
experience with it:
1 - 100 of 120 matches
Mail list logo
