[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
From: "Alexey A." <hakavlad () gmail ! com>
Date: 2020-09-14 11:35:11
Message-ID: CADrZ5ZVwN+iiZaCROk2-LyJkpRPzU33D+34fyrKOdAo3MNh6dA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> may be different for GNOME with JIT'ed code
> potentially getting swapped out
How to recognize JIT'ed code? Do you mean that we shouldn't lock it?
=D0=BF=D0=BD, 14 =D1=81=D0=B5=D0=BD=D1=82. 2020 =D0=B3. =D0=B2 20:17, Benja=
min Berg <bberg@redhat.com>:
> On Sun, 2020-09-13 at 16:47 +0000, Alexey Avramov wrote:
> > > So with
> > > applications started, you might get higher.
> >
> > I think we should protect only basic GUI. On computers with 16G+ RAM
> > locking 1G memory with apps should not be a problem if it helps to
> > improve responsiveness.
>
> Yup, fully agree. We only need to make sure the user remains in
> control, we don't need to save random apps.
>
> > > Was that with or without swap?
> >
> > It was without swap, but with swap it has the same effect (faster
> > killer coming and system reclaiming) + responsiveness was improved
> > during heavy swapping.
>
> Yeah. I think things may be different for GNOME with JIT'ed code
> potentially getting swapped out.
>
> > > I feel that uresourced is just nicer conceptually.
> > > So uresourced is
> > > going to be ineffective for KDE for the time being.
> >
> > However, the advantage of prelockd is that may be used on old systems
> > with any DE and any file system and an init. On Debian 9 Mate locking
> > 150-200M takes very good effect. On Fedora with LXDE 200M is also
> > good value.
>
> Entirely true. I just personally prefer aiming for the long term here.
>
> Benjamin
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o=
rg
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><br></div><div>> may be different for GNOME with JIT'ed \
code<br> > potentially getting swapped out</div><div><br></div><div>How to \
recognize JIT'ed code? Do you mean that we shouldn't lock \
it?<br></div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">пн, 14 сент. 2020 г. в 20:17, Benjamin Berg <<a \
href="mailto:bberg@redhat.com">bberg@redhat.com</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On Sun, 2020-09-13 at 16:47 +0000, Alexey Avramov \
wrote:<br> > > So with<br>
> > applications started, you might get higher.<br>
> <br>
> I think we should protect only basic GUI. On computers with 16G+ RAM<br>
> locking 1G memory with apps should not be a problem if it helps to<br>
> improve responsiveness.<br>
<br>
Yup, fully agree. We only need to make sure the user remains in<br>
control, we don't need to save random apps.<br>
<br>
> > Was that with or without swap?<br>
> <br>
> It was without swap, but with swap it has the same effect (faster<br>
> killer coming and system reclaiming) + responsiveness was improved<br>
> during heavy swapping.<br>
<br>
Yeah. I think things may be different for GNOME with JIT'ed code<br>
potentially getting swapped out.<br>
<br>
> > I feel that uresourced is just nicer conceptually.<br>
> > So uresourced is<br>
> > going to be ineffective for KDE for the time being.<br>
> <br>
> However, the advantage of prelockd is that may be used on old systems<br>
> with any DE and any file system and an init. On Debian 9 Mate locking<br>
> 150-200M takes very good effect. On Fedora with LXDE 200M is also<br>
> good value.<br>
<br>
Entirely true. I just personally prefer aiming for the long term here.<br>
<br>
Benjamin<br>
_______________________________________________<br>
devel mailing list -- <a href="mailto:devel@lists.fedoraproject.org" \
target="_blank">devel@lists.fedoraproject.org</a><br> To unsubscribe send an email to \
<a href="mailto:devel-leave@lists.fedoraproject.org" \
target="_blank">devel-leave@lists.fedoraproject.org</a><br> Fedora Code of Conduct: \
<a href="https://docs.fedoraproject.org/en-US/project/code-of-conduct/" \
rel="noreferrer" target="_blank">https://docs.fedoraproject.org/en-US/project/code-of-conduct/</a><br>
List Guidelines: <a href="https://fedoraproject.org/wiki/Mailing_list_guidelines" \
rel="noreferrer" target="_blank">https://fedoraproject.org/wiki/Mailing_list_guidelines</a><br>
List Archives: <a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org" \
rel="noreferrer" target="_blank">https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org</a><br>
</blockquote></div>
[Attachment #6 (text/plain)]
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic