From: William Lee Irwin III <wli@holomorphy.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Robert Love <rml@tech9.net>,
Russell Lewis <spamhole-2001-07-16@deming-os.org>,
linux-kernel@vger.kernel.org
Subject: Re: Looking for links: Why Linux Doesn't Page Kernel Memory?
Date: Sat, 27 Jul 2002 18:48:13 -0700 [thread overview]
Message-ID: <20020728014813.GH2907@holomorphy.com> (raw)
In-Reply-To: <Pine.LNX.4.44L.0207261617020.3086-100000@imladris.surriel.com>
On Fri, Jul 26, 2002 at 04:18:56PM -0300, Rik van Riel wrote:
> Large pages and/or shared page tables should be more than
> sufficient to handle all 'benign' real workloads.
> However, 'malicious' workloads can easily generate the
> need for more pagetables than what will fit into physical
> RAM; at that point you just _have_ to throw some of these
> page tables out of RAM. If the data can be reconstructed
> from the VMA and the page cache, we can just blow the page
> table away. If it can't, we have to come up with another
> solution (maybe as simple as killing the application).
If I can poke at the malice & sufficiency bits, the workloads
triggering pagetable memory exhaustion seem to be:
(1) forking server
(2) memory-sharing constellation of processes
(3) university workload, i.e. [tens of] thousands of idle /bin/sh's etc.
(4) someone mapping a large object (64-bit)
(5) large address space coverage over time with mmap/mremap/etc. (64-bit)
(4) and (5) both involve only a single task, largely innocent of trying
to do anything industrial-strength. Yes. It's that easy to do.
Databases on 32-bit appear to be hybrids of (1) and (2), and on 64-bit,
combinations of (1), (2), (4), and (5).
Of these workloads, only (2) is feasible through pagetable sharing and
cooperation from userspace, and only (4) is feasible though large pages
and cooperation from userspace. All of these exceed physical memory
bounds, not just virtual, and hence none are solved by pte-highmem.
64-bit doesn't have highmem so (4) and (5) are immune to it anyway. The
failure mode is typically deadlock, but SCSI panics were often seen in
2.4.x, along with other nondeterministic failures.
Feasible database workloads on 32-bit machines running mainline kernels
seem to run with between 50% and 90% of physical memory consumed by
process pagetables and severe restrictions on the number of clients
that attempt to connect. When larger proportions of memory are consumed
by process pagetables, kernel deadlock often ensues.
Cheers,
Bill
next prev parent reply other threads:[~2002-07-28 1:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-26 17:59 Looking for links: Why Linux Doesn't Page Kernel Memory? Russell Lewis
2002-07-26 18:17 ` Andreas Dilger
2002-07-26 18:21 ` Robert Love
2002-07-26 19:10 ` Rik van Riel
2002-07-26 19:16 ` Robert Love
2002-07-26 19:18 ` Rik van Riel
2002-07-28 1:48 ` William Lee Irwin III [this message]
2002-07-28 1:56 ` Rik van Riel
2002-07-26 19:25 ` Richard B. Johnson
2002-07-26 19:33 ` Alan Cox
2002-07-26 19:43 ` Mike Castle
2002-07-27 16:24 ` David Woodhouse
2002-07-27 16:56 ` Rik van Riel
2002-07-28 0:59 ` Daniel Phillips
2002-07-28 20:07 ` Alan Cox
2002-07-28 0:40 ` Daniel Phillips
2002-07-28 0:57 ` William Lee Irwin III
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=20020728014813.GH2907@holomorphy.com \
--to=wli@holomorphy.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=rml@tech9.net \
--cc=spamhole-2001-07-16@deming-os.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.