From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
To: Alexander Kjeldaas <astor@guardian.no>
Cc: security-audit@ferret.lmh.ox.ac.uk, Linux MM <linux-mm@kvack.org>
Subject: Re: accounting for kernel resources
Date: Wed, 24 Jun 1998 22:19:29 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.3.96.980624221108.27393F-100000@mirkwood.dummy.home> (raw)
In-Reply-To: <19980624110227.38267@lucifer.guardian.no>
On Wed, 24 Jun 1998, Alexander Kjeldaas wrote:
> I know Alan Cox has given some thought to accounting the memory
> mapping resources allocated by the kernel (pte). I haven't seen the
These should probably be allocated to both the process
involved _and_ to a special page_tbl statistic. It would
be nice to see how much overhead the pagetables _really_
take up (and their impact on memory fragmentation).
Also, this statistic will be somewhat needed once I implement
the zone allocator...
> design so I don't know how it works, but I'd like the kernel to
> account for resources allocated more aggressively. A simple step would
> be to let all structures allocated by kmalloc and associated with a
> process be accounted for. Ideally, the only thing the kernel should be
This is a very good idea, but we must be careful about some
things...
> responsible for should be caches that can be shrinked without having
> any user-land effects. The accounting should not naively count the
> number of bytes allocated, but take into account alignment-issues.
What about network buffers and other stuff that's been
pushed 'under' the current process but that doesn't really
belong to it?
There are several border cases, we probably should just
give an extra argument to get_free_page() saying to which
entitie(s) the memory should be charged...
> I think implementing this should be fairly easy - basically extending
> rlimits and making a few macros. However, there might be some
> border-cases where accounting is difficult. I can't think of them, but
> others on this list might come up with something.
DMA buffers, for character devices we probably want to
charge the process using it, for block devices the choice
is less obvious... (TAR-usage, filesystem, database on raw
disk, etc)
All shared memory things. Buffers replicated from a written-too
pagecache page (not dirty since the pagecache uses write-through
to the buffer cache). Network buffers, filehandles and other
stuff that's too small to charge to individual processes. These
things grow large however when a process uses tons of 'em (500
filehandles).
The memory used to index the above cruft :)
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
parent reply other threads:[~1998-06-24 21:31 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <19980624110227.38267@lucifer.guardian.no>]
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=Pine.LNX.3.96.980624221108.27393F-100000@mirkwood.dummy.home \
--to=h.h.vanriel@phys.uu.nl \
--cc=astor@guardian.no \
--cc=linux-mm@kvack.org \
--cc=security-audit@ferret.lmh.ox.ac.uk \
/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