hi,
Am Freitag, dem 10.06.2022 um 20:16 +0200 schrieb Sebastien Bacher:
> Le 09/06/2022 à 21:19, Dan Streetman a écrit :
> > Personally, I think this is the correct option. 1GB is not a good
> > default swap size.
>
> Did we ever consider doing the same than fedora is doing there?
>
>
Le 09/06/2022 à 21:19, Dan Streetman a écrit :
Personally, I think this is the correct option. 1GB is not a good
default swap size.
Did we ever consider doing the same than fedora is doing there?
https://fedoraproject.org/wiki/Changes/SwapOnZRAM
Cheers,
Sebastien Bacher
--
ubuntu-devel
Le 10/06/2022 à 17:52, Julian Andres Klode a écrit :
but I think the main
problem is that there is no desktop integration telling the user
why something was killed so they assume malfunction.
If we had a popup after an oom event saying
The application firefox was closed to maintain system
As a user with low RAM on my system (4GB) and a slow HDD (slow disk access
means slow swap access), I believe Firefox waits way too long to unload its
tabs. If only 5% of swap is free, it's too late. First, because the system
has already chugged extremely badly from using any swap in the first
On Fri, Jun 10, 2022 at 08:24:41AM -0700, Steve Langasek wrote:
> On Fri, Jun 10, 2022 at 11:40:52AM +0200, Julian Andres Klode wrote:
> > On Thu, Jun 09, 2022 at 03:19:36PM -0400, Dan Streetman wrote:
>
> > > > I think that either option (1) or (3) would be the most reasonable --
> > > > maybe
On Fri, Jun 10, 2022 at 11:40:52AM +0200, Julian Andres Klode wrote:
> On Thu, Jun 09, 2022 at 03:19:36PM -0400, Dan Streetman wrote:
> > > I think that either option (1) or (3) would be the most reasonable --
> > > maybe trying (1) first and falling back to (3) if necessary. If anyone
> > > has
On Jun 9 2022, at 2:19 pm, Dan Streetman wrote:
> Was systemd-oomd enabled by default for a specific reason? The kernel
> is quite able to handle oom situations itself, and has been for years,
> so while I'm not trying to suggest systemd-oomd is without any use
> case, I'm skeptical that
On Fri, Jun 10, 2022 at 5:21 AM Ernst Sjöstrand wrote:
>
> Den fre 10 juni 2022 kl 07:36 skrev Olivier Tilloy
> :
>>
>>
>>
>> On Fri, Jun 10, 2022 at 1:49 AM Steve Langasek
>> wrote:
>>>
>>> On Thu, Jun 09, 2022 at 01:00:45PM -0400, Nick Rosbrook wrote:
>>> > In the reports I refer to above,
Den fre 10 juni 2022 kl 07:36 skrev Olivier Tilloy <
olivier.til...@canonical.com>:
>
>
> On Fri, Jun 10, 2022 at 1:49 AM Steve Langasek
> wrote:
>
>> On Thu, Jun 09, 2022 at 01:00:45PM -0400, Nick Rosbrook wrote:
>> > In the reports I refer to above, applications are being killed due to
>> >
Le 10/06/2022 à 11:40, Julian Andres Klode a écrit :
The bug reports we see show that systemd-oomd is working correctly:
The browser gets killed, the system remains responsive without having
become unresponsive as would be the usual case.
It might be working 'correctly' but is not perceived as
On Thu, Jun 09, 2022 at 03:19:36PM -0400, Dan Streetman wrote:
>
> >
> > I think that either option (1) or (3) would be the most reasonable --
> > maybe trying (1) first and falling back to (3) if necessary. If anyone
> > has an opinion on this, or can think of other options, I would
> >
On Thu, Jun 09, 2022 at 01:00:45PM -0400, Nick Rosbrook wrote:
> Hi,
>
> During the 22.04 cycle, we enabled systemd-oomd [1] by default on
> desktop. Since then, there have been reports of systemd-oomd killing
> user applications too frequently (e.g. browsers, IDEs, and gnome-shell
> in some
Hi,
On Thu, 9 Jun 2022 at 20:20, Dan Streetman wrote:
> On Thu, Jun 9, 2022 at 3:03 PM Nick Rosbrook
> wrote:
> >
> > Hi,
> >
> > During the 22.04 cycle, we enabled systemd-oomd [1] by default on
> > desktop. Since then, there have been reports of systemd-oomd killing
> > user applications too
13 matches
Mail list logo
