From: Rich Freeman <rich0@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Limiting amount of memory a program can use.
Date: Sun, 28 Aug 2022 10:21:19 -0400 [thread overview]
Message-ID: <CAGfcS_=hVbXr+N6-4ZWiBrWbJUSAmrDJXur+05VG+kK0oO-K8Q@mail.gmail.com> (raw)
In-Reply-To: <464b2b22-6c7c-6dd1-c0b0-b4905222943f@gmail.com>
On Sun, Aug 28, 2022 at 8:24 AM Dale <rdalek1967@gmail.com> wrote:
>
> What I would like to do is limit the amount of memory torrent
> software can use.
While ulimit/cgroups/etc will definitely do the job, they're probably
not the solution you want. Those will cause memory allocation to
fail, and I'm guessing at that point your torrent software will just
die.
I'd see if you can do something within the settings of the program to
limit its memory use, and then use a resource limit at the OS level as
a failsafe, so that a memory leak doesn't eat up all your memory.
Otherwise your next email will be asking how to automatically restart
a dead service. Systemd has support for that built-in, and there are
also options for non-systemd, but you're going to be constantly having
restarts and it might not even run for much time at all depending on
how bad the problem is. It is always best to tame memory use within
an application.
Something I wish linux supported was discardable memory, for
caches/etc. A program should be able to allocate memory while passing
a hint to the kernel saying that the memory is discardable. If the
kernel is under memory pressure it can then just deallocate the memory
and then have some way to notify the process that the memory no longer
is allocated. That might optionally support giving warning first, or
it might be some kind of new trappable exception for segfaults to
discarded memory. (Since access to memory doesn't involve system
calls it might be hard to have more graceful error handling. I guess
an option would be to first tell the kernel to lock the memory before
accessing it, then release the lock, so that the memory isn't
discarded after checking that it is safe.)
--
Rich
next prev parent reply other threads:[~2022-08-28 14:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-28 12:24 [gentoo-user] Limiting amount of memory a program can use Dale
2022-08-28 12:56 ` Peter Humphrey
2022-08-28 13:03 ` Michael
2022-08-28 13:10 ` Michael
2022-08-28 14:21 ` Rich Freeman [this message]
2022-08-28 15:32 ` Wols Lists
2022-08-28 21:12 ` Rich Freeman
2022-08-28 14:24 ` Mark Knecht
2022-08-28 16:48 ` ralfconn
2022-08-29 5:50 ` Dale
2022-08-29 16:07 ` Matt Connell
2022-08-29 21:01 ` mad.scientist.at.large
2022-08-29 21:11 ` Dale
2022-08-30 13:56 ` Matt Connell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGfcS_=hVbXr+N6-4ZWiBrWbJUSAmrDJXur+05VG+kK0oO-K8Q@mail.gmail.com' \
--to=rich0@gentoo.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox