Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> memory is executable code, but it behaves like > other process memory such as the heap or the stack Seems like it is not a problem: with GNOME effect is the same as with other environments. пн, 14 сент. 2020 г. в 21:14, Benjamin Berg : > On Mon, 2020-09-14 at 20:35 +0900, Alexey A. wrote: > >

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, 2020-09-14 at 20:35 +0900, Alexey A. wrote: > > > 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? I don't think you can protect it using your tool, as it lives in anonymous mappings.

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> 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? пн, 14 сент. 2020 г. в 20:17, Benjamin Berg : > On Sun, 2020-09-13 at 16:47 +, Alexey Avramov wrote: > > > So with > > > applications started,

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sun, 2020-09-13 at 16:47 +, 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

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> If you actually tried to use the memory it says in MemAvailable, you > may very well already get bad side effects as the kernel needs to > reclaim memory used for other purposes (file caches, mmap'ed > executables, heap, …). Depending on the workload, this may already > cause the system to start

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> 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. > Was that with or without swap? It was without swap, but with swap it has the

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sat, 2020-09-12 at 20:53 +, Alexey Avramov wrote: > > how much memory that amounts to in the usual scenarios > > 700M on F32 without any apps started. That seems like quite a lot. I mean, we get into a similar region of memory that EarlyOOM would be protecting with no apps started. So

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> how much memory that amounts to in the usual scenarios 700M on F32 without any apps started. Largest file: (207.9M) /usr/lib/locale/locale-archive Files list with its sizes: https://pastebin.com/Hpr6D3Sv Locking even 250M-300M takes good effect. For example, demo:

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> On 20 Jul 2020, at 15:40, Stephen John Smoogen wrote: > > On Mon, 20 Jul 2020 at 05:04, Kevin Kofler > wrote: >> >> John M. Harris Jr wrote: >>> Userspace isn't dead when a system is thrashing. Your software is still >>> running. If it gets killed, you're

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, 20 Jul 2020 at 05:04, Kevin Kofler wrote: > > John M. Harris Jr wrote: > > Userspace isn't dead when a system is thrashing. Your software is still > > running. If it gets killed, you're most likely going to lose your data. > > The thing is, there are various levels of thrashing. In some

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, Jul 20, 2020 at 10:55 am, Kevin Kofler wrote: That said, I do not see how the EarlyOOM heuristic, which allows, depending on the exact settings, something like 80-90% of swap to be used IN ADDITION to 90+% RAM (and will only start doing anything if BOTH RAM and swap are full) can

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, 2020-07-20 at 10:55 +0200, Kevin Kofler wrote: > That said, I do not see how the EarlyOOM heuristic, which allows, depending > on the exact settings, something like 80-90% of swap to be used IN ADDITION > to 90+% RAM (and will only start doing anything if BOTH RAM and swap are > full)

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

John M. Harris Jr wrote: > Userspace isn't dead when a system is thrashing. Your software is still > running. If it gets killed, you're most likely going to lose your data. The thing is, there are various levels of thrashing. In some cases, the system is so busy that you have no chance to bring

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

Hello, On Sunday, July 19, 2020 2:53:32 AM MDT John M. Harris Jr wrote: > On Sunday, July 19, 2020 1:47:23 AM MST Alexey A. wrote: > > > >Killing users' programs needlessly is not welcome > > > > > > Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing > > users' programs

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> Userspace isn't dead If something looks like dead it is dead. A userspace that does not respond to user actions is a dead userspace. вс, 19 июл. 2020 г. в 17:54, John M. Harris Jr : > On Sunday, July 19, 2020 1:47:23 AM MST Alexey A. wrote: > > >Killing users' programs needlessly is not

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sunday, July 19, 2020 1:47:23 AM MST Alexey A. wrote: > >Killing users' programs needlessly is not welcome > > Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing > users' programs needlessly": system-wide available memory may be not > exhausted, but OOM killer will be

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>Killing users' programs needlessly is not welcome Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing users' programs needlessly": system-wide available memory may be not exhausted, but OOM killer will be invoked in this cgroup. >The goal is to ensure the kernel can keep

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Saturday, July 18, 2020 6:33:11 PM MST Brandon Nielsen wrote: > What about the case of the developer whose code accidentally does > something that blows through all available memory, leading to swap > thrashing. I've been there. The system is very much unusable, to the > point where a user

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/18/20 5:09 PM, John M. Harris Jr wrote: On Saturday, July 18, 2020 3:25:35 AM MST Benjamin Berg wrote: But thrashing scenarios are exactly that, *technically* running but *practically* dead. Thrashing doesn't mean the system is unusable, or anything of the sort. It's only an issue if

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Saturday, July 18, 2020 3:25:35 AM MST Benjamin Berg wrote: > On Fri, 2020-07-17 at 19:44 -0700, John M. Harris Jr wrote: > > On Friday, July 17, 2020 10:06:53 AM MST Benjamin Berg wrote: > > > What we achieve by killing a process is that we give the kernel more > > > flexibility in how it

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Fri, 2020-07-17 at 19:44 -0700, John M. Harris Jr wrote: > On Friday, July 17, 2020 10:06:53 AM MST Benjamin Berg wrote: > > What we achieve by killing a process is that we give the kernel more > > flexibility in how it manages the available memory. It really doesn't > > matter what you kill,

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sat, 2020-07-18 at 05:07 +0900, Alexey A. wrote: > > And this will turn bad quickly, as it will eventually > > include the executables/libraries that must be loaded as they are doing > > work! > > > So, we don't want to get the kernel into the situation where it must > > remove

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Friday, July 17, 2020 10:06:53 AM MST Benjamin Berg wrote: > On Fri, 2020-07-17 at 09:12 -0700, John M. Harris Jr wrote: > > On Tuesday, July 14, 2020 1:18:08 AM MST Benjamin Berg wrote: > > > So, we don't want to get the kernel into the situation where it must > > > remove

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> And this will turn bad quickly, as it will eventually > include the executables/libraries that must be loaded as they are doing > work! > So, we don't want to get the kernel into the situation where it must > remove executables/libraries from main memory. If that happens, you can > end up

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Fri, 2020-07-17 at 09:12 -0700, John M. Harris Jr wrote: > On Tuesday, July 14, 2020 1:18:08 AM MST Benjamin Berg wrote: > > So, we don't want to get the kernel into the situation where it must > > remove executables/libraries from main memory. If that happens, you can > > end up hitting the

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tuesday, July 14, 2020 1:18:08 AM MST Benjamin Berg wrote: > So, we don't want to get the kernel into the situation where it must > remove executables/libraries from main memory. If that happens, you can > end up hitting the disk for *every* function call. If this is true, then we shouldn't

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, 2020-07-13 at 19:25 -0600, Chris Murphy wrote: > On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg wrote: > > If MemAvailable drops below 250MiB (roughly 6GiB * 4%), then this means > > that we have less than 500MiB left for file caches. If we can't swap > > (remember, swap is already pretty

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg wrote: > > If MemAvailable drops below 250MiB (roughly 6GiB * 4%), then this means > that we have less than 500MiB left for file caches. If we can't swap > (remember, swap is already pretty full too), then a big chunk of these > caches need to be

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, Jul 13, 2020 at 11:56 AM John M. Harris Jr wrote: > > On Monday, July 13, 2020 10:48:03 AM MST Samuel Sieb wrote: > > On 7/13/20 8:21 AM, John M. Harris Jr wrote: > > > > > On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: > > > > > >> But, I also think that the people

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tue, 2020-07-14 at 00:55 +0900, Alexey A. wrote: > > MemAvailable is a bad heuristic, it does *not* represent "free" > > memory. > > MemAvailable is a good heuristic, it does represent available > memory. Maybe. But the point is that I expect a system to be in trouble long before the value

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Monday, July 13, 2020 10:48:03 AM MST Samuel Sieb wrote: > On 7/13/20 8:21 AM, John M. Harris Jr wrote: > > > On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: > > > >> But, I also think that the people proposing this have done quite a lot > >> of testing to find reasonable values

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/13/20 8:21 AM, John M. Harris Jr wrote: On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: But, I also think that the people proposing this have done quite a lot of testing to find reasonable values for various scenarios. If they have done their job correctly, then EarlyOOM will

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> MemAvailable is a bad heuristic, it does *not* represent "free" > memory. MemAvailable is a good heuristic, it does represent available memory. вт, 14 июл. 2020 г. в 00:49, Benjamin Berg : > On Mon, 2020-07-13 at 08:21 -0700, John M. Harris Jr wrote: > > On Monday, July 13, 2020 1:58:30 AM

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, 2020-07-13 at 08:21 -0700, John M. Harris Jr wrote: > On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: > > But, I also think that the people proposing this have done quite a lot > > of testing to find reasonable values for various scenarios. If they > > have done their job

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Mon, Jul 13, 2020 at 9:22 AM John M. Harris Jr wrote: > > On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: > > But, I also think that the people proposing this have done quite a lot > > of testing to find reasonable values for various scenarios. If they > > have done their job

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: > But, I also think that the people proposing this have done quite a lot > of testing to find reasonable values for various scenarios. If they > have done their job correctly, then EarlyOOM will *not* prevent you > from fully utilizing

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sun, 2020-07-12 at 14:46 -0700, John M. Harris Jr wrote: > That sounds like an excellent idea, but I'm not convinced that killing users' > processes, while there's still tons of memory free available, is actually an > improvement. I think you should rather think of "MemAvailable" as a

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/10/20 11:12 PM, John M. Harris Jr wrote: > On Thursday, July 9, 2020 2:19:27 PM MST Przemek Klosowski via devel wrote: >> On 7/9/20 8:44 AM, Kevin Kofler wrote: >> >>> Przemek Klosowski via devel wrote: >>> * disk access is literally O(1) slower than RAM access >>> >>> This

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Saturday, July 11, 2020 2:36:04 PM MST Neal Gompa wrote: > There's a difference between half-baked and a roadmap of incremental > improvement. This Change is an example of the latter. If anything, > your fanciful and speculative conjecture has done only harm for your > credibility. You continue

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thu, 2020-07-09 at 07:51 -0700, John M. Harris Jr wrote: > What's the KDE SIG's rationale behind supporting this? This actively limits > the amount of RAM that end users are able to make use of. The more RAM the > end > user has, the more RAM is not available for use, because EarlyOOM will

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sun, 2020-07-12 at 12:46 +0200, Kevin Kofler wrote: > Neal Gompa wrote: > > There's a difference between half-baked and a roadmap of incremental > > improvement. This Change is an example of the latter. > > No, it is actually an example of deliberately implementing a simplistic > "solution"

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

Neal Gompa wrote: > There's a difference between half-baked and a roadmap of incremental > improvement. This Change is an example of the latter. No, it is actually an example of deliberately implementing a simplistic "solution" that lags behind the state of the art on the grounds that it is

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sat, Jul 11, 2020 at 5:15 PM John M. Harris Jr wrote: > > On Saturday, July 11, 2020 11:43:29 AM MST Chris Murphy wrote: > > It's known from the outset that earlyoom is temporary. And as the > > resource control picture more fully develops on the desktop, both > > GNOME and KDE, that we have

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sat, Jul 11, 2020 at 3:15 PM John M. Harris Jr wrote: > > On Saturday, July 11, 2020 11:43:29 AM MST Chris Murphy wrote: > > It's known from the outset that earlyoom is temporary. And as the > > resource control picture more fully develops on the desktop, both > > GNOME and KDE, that we have

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Saturday, July 11, 2020 11:43:29 AM MST Chris Murphy wrote: > It's known from the outset that earlyoom is temporary. And as the > resource control picture more fully develops on the desktop, both > GNOME and KDE, that we have an eye on a PSI based approach. It's a > long arc with multiple

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

El sáb., 11 jul. 2020 a las 16:39, Benjamin Berg () escribió: > On Sat, 2020-07-11 at 14:31 -0300, Sergio Belkin wrote: > > My only question is if measuring memory pressure is a better indication. > > If nohang-desktop uses PSI, isn't it a more proper solution? > > The basic problem is that PSI

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sat, 2020-07-11 at 14:31 -0300, Sergio Belkin wrote: > My only question is if measuring memory pressure is a better indication. > If nohang-desktop uses PSI, isn't it a more proper solution? The basic problem is that PSI can only be reactive. You need to measure it over a period of time and

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sat, Jul 11, 2020 at 11:32 AM Sergio Belkin wrote: >> >> My suggestion is to stop the 'complaining for the sake of complaining' >> phase of the feature. And move to the "when I do X Y Z, this other app >> is killed off - how to tweak this?" And then does the tweak represent >> covering an edge

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> > My suggestion is to stop the 'complaining for the sake of complaining' > phase of the feature. And move to the "when I do X Y Z, this other app > is killed off - how to tweak this?" And then does the tweak represent > covering an edge case? Or is it good enough to be the new default? > >

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thursday, July 9, 2020 2:19:27 PM MST Przemek Klosowski via devel wrote: > On 7/9/20 8:44 AM, Kevin Kofler wrote: > > > Przemek Klosowski via devel wrote: > > > >>* disk access is literally O(1) slower than RAM access > > > > This notation is meaningless. By the definition of the O

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Friday, July 10, 2020 2:27:02 AM MST Kevin Kofler wrote: > Matthew Miller wrote: > > > I also don't see any reason to be required to keep unsolicited negative > > "private" emails secret. There's no agreement that they should be. > > However, I would request that you ignore them rather than

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

> Matthew Miller wrote: > > Well, as I understand it, the main reason he is sending those private > replies is that he was banned from the mailing list, or put on moderation or > something. > > If this mailing list were actually a place where people are allowed to voice > their technical

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

Matthew Miller wrote: > I also don't see any reason to be required to keep unsolicited negative > "private" emails secret. There's no agreement that they should be. > However, I would request that you ignore them rather than bringing them > back to the list. We can unsubscribe and moderate, but we

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/9/20 8:44 AM, Kevin Kofler wrote: Przemek Klosowski via devel wrote: * disk access is literally O(1) slower than RAM access This notation is meaningless. By the definition of the O notation, O(1)=O(1)=O(k) for any constant k. Yes, you are right of course, but I just hope that

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thu, Jul 9, 2020 at 12:53 PM Brandon Nielsen wrote: > > On 7/9/20 12:24 PM, Alexey A. wrote: > > I agree. I think that 4GB cap is too small and 4 GB may be used quickly. > > > > > Since the values being used seem to have been determined somewhat > heuristically for both EarlyOOM and

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thursday, July 9, 2020 9:22:01 AM MST Alexey A. wrote: > >You can limit the process with cgroups > > In this case the process will be killed by OOM killer. Note that OOM killer > exists by default. Limiting cgroup means the OOM killer will be invoked in > the cgroup. With earlyoom you database

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/9/20 12:24 PM, Alexey A. wrote: I agree. I think that 4GB cap is too small and 4 GB may be used quickly. Since the values being used seem to have been determined somewhat heuristically for both EarlyOOM and SwapOnZRAM, I was wondering if there was any prediction for how the values

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thu, Jul 09, 2020 at 10:40:39AM -0700, John M. Harris Jr wrote: > I briefly discussed the situation with bcotton, and that's how it'll handle > that in the future. I wasn't aware of the particular situation. Thanks John! -- Matthew Miller Fedora Project Leader

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thursday, July 9, 2020 10:32:06 AM MST Matthew Miller wrote: > On Thu, Jul 09, 2020 at 08:46:57AM -0700, John M. Harris Jr wrote: > > > On Thursday, July 9, 2020 8:17:50 AM MST you wrote: > > > > > keep private mail private idiot > > > > > > You're responding to my post on a mailing list. I

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thu, Jul 09, 2020 at 08:46:57AM -0700, John M. Harris Jr wrote: > On Thursday, July 9, 2020 8:17:50 AM MST you wrote: > > keep private mail private idiot > > You're responding to my post on a mailing list. I don't see any reason to > keep > this private. I'm not the only one on this list

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>75% and 6G >for the cap might be better. I agree. I think that 4GB cap is too small and 4 GB may be used quickly. >I regularly see 3 to 1 and even 4 to 1. It's true. It's easy to get 4:1 with browser. In fact, the compression ratio is highly dependent on the workload. I get 1.4:1 with blender,

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thu, Jul 9, 2020 at 8:52 AM John M. Harris Jr wrote: > What's the KDE SIG's rationale behind supporting this? This actively limits > the amount of RAM that end users are able to make use of. The more RAM the end > user has, the more RAM is not available for use, because EarlyOOM will kill >

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>You can limit the process with cgroups In this case the process will be killed by OOM killer. Note that OOM killer exists by default. Limiting cgroup means the OOM killer will be invoked in the cgroup. With earlyoom you database server will get SIGTERM and maybe will gracefully shutdown. пт, 10

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>By killing their software, while it's legitimately using RAM, as expected? Memory usage causes system hang is not legitimately using RAM. Expected behavior is killing memory hog. чт, 9 июл. 2020 г. в 23:53, John M. Harris Jr : > On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > >

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thursday, July 9, 2020 8:17:50 AM MST you wrote: > keep private mail private idiot You're responding to my post on a mailing list. I don't see any reason to keep this private. I'm not the only one on this list that you've attempted to contact directly with this sort of comment either, and I

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/8/20 11:15 PM, John M. Harris Jr wrote: >> * disk access is literally O(1) slower than RAM access > This is just false, and you can prove that on your own system using only > `dd`. > In fact, if your system is newer than my Lenovo ThinkPad X200 Tablet, you'll > probably have even

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thursday, July 9, 2020 7:57:25 AM MST Reindl Harald (privat) wrote: > Am 09.07.20 um 16:53 schrieb John M. Harris Jr: > > On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > >> +1 This would be a genuine improvement for end users! > > > > In what way do you believe this will be an

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thu, Jul 9, 2020 at 7:51 am, John M. Harris Jr wrote: There's absolutely no justification for this, as I see it. You're willfully ignoring what everybody else is telling you: we don't want out-of-control applications to bring down the desktop. GNOME doesn't want it, and KDE doesn't want

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

John M. Harris Jr wrote: > On Thursday, July 9, 2020 5:25:36 AM MST Rex Dieter wrote: >> John M. Harris Jr wrote: >> >> >> > That's not what this discussion results from. This discussion results >> > from >> > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM >> > killing our

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote: > +1 This would be a genuine improvement for end users! In what way do you believe this will be an improvement for end users? By killing their software, while it's legitimately using RAM, as expected? How exactly is that beneficial?

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Thursday, July 9, 2020 5:25:36 AM MST Rex Dieter wrote: > John M. Harris Jr wrote: > > > > That's not what this discussion results from. This discussion results > > from > > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing > > our applications at random, and ruining

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

El mar., 30 jun. 2020 a las 10:26, Ben Cotton () escribió: > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > == Summary == > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install > earlyoom package, and enable it by default. If both RAM and swap go below > 10% free, earlyoom

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

Przemek Klosowski via devel wrote: > * disk access is literally O(1) slower than RAM access This notation is meaningless. By the definition of the O notation, O(1)=O(1)=O(k) for any constant k. Kevin Kofler ___ devel mailing list --

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

John M. Harris Jr wrote: > That's not what this discussion results from. This discussion results from > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing > our applications at random, and ruining our desktop experience. This is full of inaccurate statements 1. The KDE

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Wednesday, July 8, 2020 12:53:05 PM MST Przemek Klosowski via devel wrote: > On 7/8/20 12:15 PM, John M. Harris Jr wrote: > > Really, this is starting to sound like it's more of an issue with web > > browsers, and less of a problem with our current configurations, without > > EarlyOOM

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/8/20 12:15 PM, John M. Harris Jr wrote: I'd rather crash and restart where I left off than have the computer drag me along trying to save my application. Sorry, what? Why would your data not be on your system? What about "the modern way of computing" would move your data from your system

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tuesday, July 7, 2020 8:54:40 AM MST Przemek Klosowski via devel wrote: > On 7/6/20 6:49 PM, John M. Harris Jr wrote: > > Unless you're actively using all of those tabs (I don't know how you would > > be, but it's certainly possible), swap sounds like the perfect solution. > > Unless Firefox

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/6/20 6:49 PM, John M. Harris Jr wrote: Unless you're actively using all of those tabs (I don't know how you would be, but it's certainly possible), swap sounds like the perfect solution. Unless Firefox keeps JS running in there, and it's updating the DOM, these would likely be able to get

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Monday, July 6, 2020 8:47:24 AM MST Przemek Klosowski via devel wrote: > On 7/4/20 8:18 PM, John M. Harris Jr wrote: > > > I've never managed to get one of my own Fedora machines to the point of > > OOMing, and, when I have seen others do it, it's a problem that would > > have > > been solved

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On 7/4/20 8:18 PM, John M. Harris Jr wrote: I've never managed to get one of my own Fedora machines to the point of OOMing, and, when I have seen others do it, it's a problem that would have been solved by having more swap space. I am a tab hoarder so I used to wedge the browser due to memory

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Sun, Jul 5, 2020 at 12:46 AM John M. Harris Jr wrote: > > On Saturday, July 4, 2020 11:27:47 PM MST Alexey Avramov wrote: > > >Linux handles low memory situations just fine, but it's much better if you > > > > have an appropriately sized swap partition and let the kernel do its job > > > >

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>What software in the default image leads to low memory issues? Web browsers? For example, browsers, electron-based apps, blender, compilation, VM, openings files, opening file manager (once I came across this: when I opened the file manager, an uncontrolled leak occurred somewhere in the

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Saturday, July 4, 2020 11:27:47 PM MST Alexey Avramov wrote: > >Linux handles low memory situations just fine, but it's much better if you > > have an appropriately sized swap partition and let the kernel do its job > > No, by default Linux can hang at low memory condition. Huge swap space

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>Linux handles low memory situations just fine, but it's much better if you >have an appropriately sized swap partition and let the kernel do its job No, by default Linux can hang at low memory condition. Huge swap space will not help you if a leak occurs. With a large swap space, the hang can

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Friday, July 3, 2020 10:11:53 PM MST Alexey Avramov wrote: > >it should be disabled so it doesn't kill our software > > > What should people who suffer from the fact that the kernel's OOM killer > does not work, and they are forced to hard reboot (and lose unsaved data) > the computer when

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>It is also unclear that it can prevent full OOM (both >RAM and swap completely full) in all cases Kernel's killer is also cannot prevent full OOM in all cases. earlyoom prevent full OOM (and situations close to OOM) much more effective - faster (selects victim in 5-50ms, monitoring interval

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>it should be disabled so it doesn't kill our software What should people who suffer from the fact that the kernel's OOM killer does not work, and they are forced to hard reboot (and lose unsaved data) the computer when it freezes? This is a serious and very common problem that exists for a

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Wednesday, July 1, 2020 10:44:03 AM MST Alexey Avramov wrote: > >10% and 5% to 1% and 0% > > > Default values is already changed to 4% (but not more than 400 MiB) and 2% > (but not more than 200 MiB). A nonzero threshold helps maintain disk cache > and speeds up system recovery after

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>What about /usr/lib64/qt5/libexec/QtWebEngineProcess processes? These processes get oom_score_adj=300 out of the box, see https://pastebin.com/AFVU9U8X ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

Alexey A. wrote: > 2. Firefox's children processes "Web Content" gets +300 to its oom_score. > It means that earlyoom will prefer to kill firefox tabs rather than entire > browser. Similar behavior is already practiced in chromium and > electron-based apps by default. What about

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>EarlyOOM being a >userspace process that races with the memory-consuming processes and that >may end up not getting scheduled due to the very impending OOM condition >that it is trying to prevent. earlyoom consumes 1 MiB VmRSS and all memory is locked by mlockall(). earlyoom works pretty

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>10% and 5% to 1% and 0% Default values is already changed to 4% (but not more than 400 MiB) and 2% (but not more than 200 MiB). A nonzero threshold helps maintain disk cache and speeds up system recovery after correction. ___ devel mailing list --

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

>If both RAM and swap go below 10% free, earlyoom issues SIGTERM to the process with the largest oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL Fedora's earlyoom package is provided with the changed default settings: ``` EARLYOOM_ARGS="-r 0 -m 4 -M 409600 --prefer

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tue, Jun 30, 2020 at 6:30 PM Kevin Kofler wrote: > > I strongly believe that this kernel problem can only be solved within the > kernel, by a synchronous (hence race-free) hook on all allocations. > I don't disagree, but if that's not available, this is the best we have. And it's tunable (or

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tue, Jun 30, 2020 at 4:42 PM Neal Gompa wrote: > > On Tue, Jun 30, 2020 at 6:30 PM Kevin Kofler wrote: > > > > I am opposed to this change, for the same reasons I was opposed to EarlyOOM > > to begin with: this solution kills processes under arbitrary conditions that > > are neither necessary

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tue, Jun 30, 2020 at 6:30 PM Kevin Kofler wrote: > > Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > > > == Summary == > > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install > > earlyoom package, and enable it by default. If both RAM and swap go

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > == Summary == > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install > earlyoom package, and enable it by default. If both RAM and swap go below > 10% free, earlyoom issues SIGTERM to the process with the

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tuesday, June 30, 2020 6:25:02 AM MST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > == Summary == > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install > earlyoom package, and enable it by default. If both RAM and swap go below > 10% free, earlyoom

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tue, Jun 30, 2020 at 9:32 AM Neal Gompa wrote: > > * Has anyone reached out to the other spins to see if they'd like to > include it? I think it actually makes sense to do it for all Fedora > desktops. I reached out to the other KDE-based deliverables. If other spins owners want to sign on,

Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

On Tue, Jun 30, 2020 at 9:26 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/KDEEarlyOOM > > == Summary == > As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install earlyoom > package, and enable it by default. If both RAM and swap go below 10% free, > earlyoom

  1   2   >