emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: commit limit


From: Eli Zaretskii
Subject: Re: MPS: commit limit
Date: Tue, 16 Jul 2024 18:54:51 +0300

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  pipcet@protonmail.com,  yantar92@posteo.net,
>   emacs-devel@gnu.org
> Date: Tue, 16 Jul 2024 17:43:17 +0200
> 
> On Tue, Jul 16 2024, Eli Zaretskii wrote:
> 
> >> This patch adds a igc--set-commit-limit function.  It doesn't fix the
> >> problem with the assertion.  People who use the hot MPS build will
> >> probably see a normal memory full error and probably have to quit soon
> >> after that.  The others see the failed assertion and abort immediately.
> >> So the end result will not be much different.
> >
> > Is this a debugging aid?
> 
> Yes, that too.
> 
> > If so, please say that in the doc string.
> 
> It's an internal function.  Only people who know what they're doing
> should use it.

I doubt the number of people who match that description
(i.e. understand enough what the limit does to use it wisely) is large
enough to justify its existence.  VM concepts are not easily
understood and even less easily translated to practical terms of using
a modern system.  Especially when memory is allocated by sophisticated
libraries such as glibc, which have their own ideas of when and if to
release memory to the OS.

IOW, we are giving unsuspecting users a too-long rope they can
inadvertently hang themselves.

> > If that's not the reason, then why would we need to limit the amount
> > of memory MPS can commit?  I think we generally let Emacs use as much
> > memory as the system is prepared to give it, no?
> 
> It also helps to avoid thrashing on machines that don't have many GB of
> unused RAM.

There's ulimit, and if someone wants to avoid thrashing, they can do
that already.  OTOH, hitting thrashing is much safer than running out
of memory -- the latter makes the risk of losing edits much higher.

So I think this should be limited to testing, and the doc string
should warn against using the function for anything else.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]