lkml.org 
[lkml]   [1996]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Bugs and wishes in memory management area
Date

In linux.dev.kernel, article <Pine.LNX.3.91.961119213405.286A-100000@nextd.demon.co.uk>,
Mark Hemment <markhe@nextd.demon.co.uk> writes:
>
> On Tue, 19 Nov 1996, Jean Francois Martinez wrote:
> > Wishes for memory management in 2.1
> > First: Real swapping. When two processes are fighting for memory and
> > memory is tight only way to make progress is freezing one of them and
> > let the other run unimpeded for a few seconds.
>
> I'm not a fan of swapping out an entire process (is this what you mean?)
> It adds a lot of extra problems into the kernel (and hence more code),
> espically to the scheduler. While I hate to suggest someone spends
> money, if your system is thrashing the disk because of paging-out then
> you really should consider a few extra megas.

Won't work.

Consider a typical server. It runs news/mail/http or so. It's configured to
cope with a maximal mail load, OR a maximal http load, OR a bunch of
news-to-be-debatched. It'd be rather expensive to make that box run well
with AND instead of OR here.

IMHO, the only workable way to do this is to introduce a couple of load
thresholds, like "IF the load of FOO goes above BAR, stop the process which
contributes most to that load (assuming there's more than one) until the
FOO load goes below BAZ". Make BAR and BAZ configurable for a bunch of
different FOOs, and (via ulimit or similar) for a bunch of different
processes (wouldn't want our X server or xterm to get stopped, no matter
how high the load is). Try a couple of different settings and see what you
can do.

The current way of doing things is admittedly very suboptimal. I mean, two
processes should finish in roughly twice the time one process needs, right?
Well, if one of these eats and uses 60% of available physical memory, two
of those could finish in ten times that time. That's a bug, IMHO. A
difficult-to-fix bug, do be sure, but that doesn't mean the attempt
shouldn't be made.

Is there a description of the way BSD handles this problem, if any,
available electronically anywhere?

--
Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg
Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de
90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing
PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.149 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site