From: Paul Jackson <pj@sgi.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: kosaki.motohiro@jp.fujitsu.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, marcelo@kvack.org,
daniel.spang@gmail.com, riel@redhat.com,
akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
linux-fsdevel@vger.kernel.org, a1426z@gawab.com,
jonathan@jonmasters.org, zlynx@acm.org
Subject: Re: [PATCH 0/8][for -mm] mem_notify v6
Date: Tue, 19 Feb 2008 19:54:49 -0600 [thread overview]
Message-ID: <20080219195449.29ef9d1a.pj@sgi.com> (raw)
In-Reply-To: <20080219222828.GB28786@elf.ucw.cz>
Pavel, responding to pj:
> > There is not much my customers HPC jobs can do with notification before
> > swap. Their jobs either have the main memory they need to perform the
> > requested calculations with the desired performance, or their job is
> > useless and should be killed. Unlike the applications you describe,
> > my customers jobs have no way, once running, to adapt to less
> > memory.
>
> Sounds like a job for memory limits (ulimit?), not for OOM
> notification, right?
Er eh -- which one?
The only one I see that might help keep a multi-threaded job
using various kinds of memory on multiple nodes confined could
be the resident set size (RLIMIT_RSS; ulimit -m). So far as
I can tell, that one is a pure no-op in Linux.
Here's the bash list of all available ulimit (setrlimit) options:
-a All current limits are reported
-c The maximum size of core files created
-d The maximum size of a process's data segment
-e The maximum scheduling priority ("nice")
-f The maximum size of files written by the shell and its children
-i The maximum number of pending signals
-l The maximum size that may be locked into memory
-m The maximum resident set size
-n The maximum number of open file descriptors (most systems do not allow this value to be set)
-p The pipe size in 512-byte blocks (this may not be set)
-q The maximum number of bytes in POSIX message queues
-r The maximum real-time scheduling priority
-s The maximum stack size
-t The maximum amount of cpu time in seconds
-u The maximum number of processes available to a single user
-v The maximum amount of virtual memory available to the shell
-x The maximum number of file locks
Did I miss seeing one that would be useful?
Actually, given the chronic problem we've had over the years accounting
for how much memory in total (including text, data, stack, mapped
files, locked pages, kernel memory structures that an application is
using many of, ... I'd be suprised if any such ulimit existed that
actually worked for this purpose (confining an HPC jobs to using almost
exactly all the memory available to it, but no more.)
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-02-20 1:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-09 15:19 [PATCH 0/8][for -mm] mem_notify v6 KOSAKI Motohiro
2008-02-09 16:02 ` Jon Masters
2008-02-09 16:33 ` KOSAKI Motohiro
2008-02-09 16:43 ` Rik van Riel
2008-02-09 16:49 ` KOSAKI Motohiro
2008-02-11 15:36 ` [PATCH 0/8][for -mm] mem_notify v6, " Jonathan Corbet
2008-02-11 15:46 ` KOSAKI Motohiro
2008-02-17 14:49 ` Paul Jackson
2008-02-19 7:36 ` KOSAKI Motohiro
2008-02-19 15:00 ` Paul Jackson
2008-02-19 19:02 ` Rik van Riel
2008-02-19 20:18 ` Paul Jackson
2008-02-19 20:43 ` Paul Jackson
2008-02-19 22:28 ` Pavel Machek
2008-02-20 1:54 ` Paul Jackson [this message]
2008-02-20 2:07 ` Rik van Riel
2008-02-20 2:48 ` KOSAKI Motohiro
2008-02-20 4:57 ` Paul Jackson
2008-02-20 5:21 ` KOSAKI Motohiro
2008-02-20 4:36 ` Paul Jackson
2008-04-01 23:35 ` Tom May
2008-04-02 7:31 ` KOSAKI Motohiro
2008-04-02 17:45 ` Tom May
2008-04-15 0:16 ` Tom May
2008-04-16 2:30 ` KOSAKI Motohiro
2008-04-17 9:30 ` KOSAKI Motohiro
2008-04-17 19:23 ` Tom May
2008-04-18 10:07 ` KOSAKI Motohiro
2008-04-21 20:32 ` Tom May
2008-04-23 8:27 ` Daniel Spång
2008-05-01 2:07 ` Tom May
2008-05-01 15:06 ` KOSAKI Motohiro
2008-05-02 22:21 ` Tom May
2008-05-03 12:26 ` KOSAKI Motohiro
2008-05-06 5:22 ` Tom May
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=20080219195449.29ef9d1a.pj@sgi.com \
--to=pj@sgi.com \
--cc=a1426z@gawab.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=daniel.spang@gmail.com \
--cc=jonathan@jonmasters.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo@kvack.org \
--cc=pavel@ucw.cz \
--cc=riel@redhat.com \
--cc=zlynx@acm.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;
as well as URLs for NNTP newsgroup(s).