From: Martin Dalecki <dalecki@evision-ventures.com>
To: Jonathan Morton <chromi@cyberspace.org>
Cc: Rik van Riel <riel@conectiva.com.br>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"James A. Sutherland" <jas88@cam.ac.uk>,
Guest section DW <dwguest@win.tue.nl>,
Patrick O'Rourke <orourke@missioncriticallinux.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] OOM handling
Date: Sun, 25 Mar 2001 17:47:59 +0200 [thread overview]
Message-ID: <3ABE132F.E919F908@evision-ventures.com> (raw)
In-Reply-To: <l03130321b6e3c0533688@[192.168.239.101]>
Jonathan Morton wrote:
>
> >- the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> Tsk tsk tsk...
>
> >Now if you can make something which preserves the heuristics which
> >serve us so well on desktop boxes and add something that makes it
> >also work on your Oracle servers, then I'd be interested.
>
> What do people think of my "adjustments" to the existing algorithm? Mostly
> it gives extra longevity to low-UID and long-running processes, which to my
> mind makes sense for both server and desktop boxen.
>
> Taking for example an 80Mb process under my adjustments, it is reduced to
> under the badness of a new shell process after less than a week's uptime
> (compared to several months), especially if it is run as low-UID. Small,
> short-lived interactive processes still don't get *too* adversely affected,
> but a memory hog with only a few hours' uptime will still get killed with
> high probability (pretty much what we want).
>
> I didn't quite understand Martin's comments about "not normalised" -
> presumably this is some mathematical argument, but what does this actually
> mean?
Not mathematics. It's from physics. Very trivial physics, basic scool
indeed.
If you try to calculate some weightning
factors which involve different units (in this case mostly seconds and
bits)
then you will have to make sure tha those units get factorized out.
Rik is just throwing the absolute values together...
Trivial example:
"How long does it take to travel from A to B?"
"It takes about 1000sec."
"How long does it take to travel from C to D?"
"It takes about 100sec."
"Ah, so it's 10 times longer from A to B then from C to D".
Write it down - you just divide the seconds out.
In case of varying intervalls you have to normalize
measures by max/min values. Since for example the
amount of RAM in a box can vary as well. Otherwise
your algorithms will behave very differently on boxes
with low RAM in comparision to boxes with huge amounts of
it. That's what one says if he talks about an
algorithm "scalling well".
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-03-25 15:47 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-21 22:54 [PATCH] Prevent OOM from killing init Patrick O'Rourke
2001-03-21 23:11 ` Eli Carter
2001-03-21 23:40 ` Patrick O'Rourke
2001-03-21 23:48 ` Rik van Riel
2001-03-22 8:14 ` Eric W. Biederman
2001-03-22 9:24 ` Rik van Riel
2001-03-22 19:29 ` Philipp Rumpf
2001-03-22 11:47 ` Guest section DW
2001-03-22 15:01 ` Rik van Riel
2001-03-22 19:04 ` Guest section DW
2001-03-22 23:10 ` Jordi Polo
2001-03-22 16:41 ` Eric W. Biederman
2001-03-22 20:28 ` Stephen Clouse
2001-03-22 21:01 ` Ingo Oeser
2001-03-22 21:23 ` Alan Cox
2001-03-22 22:00 ` Guest section DW
2001-03-22 22:12 ` Ed Tomlinson
2001-03-22 22:52 ` Alan Cox
2001-03-22 23:27 ` Guest section DW
2001-03-22 23:37 ` Rik van Riel
2001-03-26 19:04 ` James Antill
2001-03-26 20:05 ` Rik van Riel
2001-03-22 23:40 ` Alan Cox
2001-03-23 20:09 ` Szabolcs Szakacsits
2001-03-23 22:21 ` Alan Cox
2001-03-23 22:37 ` Szabolcs Szakacsits
2001-03-23 19:57 ` Szabolcs Szakacsits
2001-03-22 22:10 ` Doug Ledford
2001-03-22 22:53 ` Alan Cox
2001-03-22 23:30 ` Doug Ledford
2001-03-22 23:40 ` Alan Cox
2001-03-22 23:43 ` Stephen Clouse
2001-03-23 19:26 ` Szabolcs Szakacsits
2001-03-23 20:41 ` Paul Jakma
2001-03-23 21:58 ` george anzinger
2001-03-24 5:55 ` Rik van Riel
2001-03-24 8:04 ` Mike Galbraith
2001-03-27 14:05 ` Scott F. Kaplan
2001-03-28 0:00 ` Rik van Riel
2001-03-30 3:18 ` Scott F. Kaplan
2001-03-30 23:03 ` Rik van Riel
2001-03-23 22:18 ` Szabolcs Szakacsits
2001-03-24 2:08 ` Paul Jakma
2001-03-23 1:31 ` Michael Peddemors
2002-03-23 0:33 ` Martin Dalecki
2001-03-22 23:53 ` Rik van Riel
2002-03-23 1:21 ` Martin Dalecki
2001-03-23 0:20 ` Stephen Clouse
2002-03-23 1:30 ` Martin Dalecki
2001-03-23 1:37 ` Rik van Riel
2001-03-23 10:48 ` Martin Dalecki
2001-03-23 14:56 ` Rik van Riel
2001-03-23 16:43 ` Guest section DW
2001-03-24 5:57 ` Rik van Riel
2001-03-25 16:35 ` Guest section DW
2001-03-23 17:26 ` James A. Sutherland
2001-03-23 17:32 ` Alan Cox
2001-03-23 18:58 ` Martin Dalecki
2001-03-23 19:45 ` Jonathan Morton
2001-03-23 23:26 ` Eric W. Biederman
2001-03-25 13:54 ` [PATCH] OOM handling Martin Dalecki
2001-03-25 15:06 ` Rik van Riel
2001-03-25 15:20 ` Martin Dalecki
2001-03-25 17:08 ` Rik van Riel
2001-03-25 15:44 ` Jonathan Morton
2001-03-25 15:47 ` Martin Dalecki [this message]
2001-03-25 16:36 ` Jonathan Morton
2001-03-26 21:34 ` Kevin Buhr
2001-03-26 22:00 ` Jonathan Morton
2001-03-25 15:30 ` [PATCH] Prevent OOM from killing init Martin Dalecki
2001-03-25 20:47 ` Stephen Satchell
2001-03-25 21:51 ` [PATCH] non-overcommit memory, improved OOM handling, safety margin (was Re: Prevent OOM from killing init) Jonathan Morton
2001-03-27 15:23 ` Pavel Machek
2001-03-23 20:16 ` [PATCH] Prevent OOM from killing init Jordi Polo
2001-03-24 0:03 ` Guest section DW
2001-03-24 7:52 ` Doug Ledford
2001-03-22 14:53 ` Patrick O'Rourke
2001-03-22 19:24 ` Philipp Rumpf
2001-03-22 22:20 ` James A. Sutherland
2001-03-23 17:31 ` Szabolcs Szakacsits
2001-03-24 5:54 ` Rik van Riel
2001-03-24 6:55 ` Juha Saarinen
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=3ABE132F.E919F908@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chromi@cyberspace.org \
--cc=dwguest@win.tue.nl \
--cc=jas88@cam.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=orourke@missioncriticallinux.com \
--cc=riel@conectiva.com.br \
/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