All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: RFC: pageable kernel-segments
Date: 17 Apr 2001 12:21:17 -0700	[thread overview]
Message-ID: <9bi53d$5n6$1@cesium.transmeta.com> (raw)
In-Reply-To: <27525795B28BD311B28D00500481B7601F11D9@ftrs1.intranet.ftr.nl>

Followup to:  <27525795B28BD311B28D00500481B7601F11D9@ftrs1.intranet.ftr.nl>
By author:    "Heusden, Folkert van" <f.v.heusden@ftr.nl>
In newsgroup: linux.dev.kernel
>
> Would anyone be intrested (besides me) in a kernel which can page
> out certain parts of itself? The kernel should be in some kind of
> vmlinux-ish (as in: uncompressed) format on disk for on-demand
> re-loading of pages which are discarded.
> Certain parts of drivers could get the __pageable prefix or so
> (like the __init parts of drivers which get removed) for letting
> the paging-code know that it can be discared if memory-pressure
> demands it.
> __pageable -code would then be things like (e.g.!) the code which
> handles the open()/close() of a device. Most of the time a device
> spends more time doing read/write/ioctl then close/open so. Also;
> hopefully there's no interrupt-sensitive code in these routines.
> I would think is usable (for example) for my 8MB ram laptop.
> Anyone any thoughts on this?
> 

VMS does this.  It at least used to have a great tendency to crash
itself, because it swapped out something that was called from a driver
that was called by the swapper -- resulting in deadlock.  You need
iron discipline for this to work right in all circumstances.

Second, it makes it quite hard to know what operations can cause a
task to sleep, since any reference to paged-out memory can require a
page-in and the associated schedule.  You almost need pointer
annotation in order for this to be safe.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

  parent reply	other threads:[~2001-04-17 19:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-17 15:57 RFC: pageable kernel-segments Heusden, Folkert van
2001-04-17 16:07 ` Disconnect
     [not found]   ` <01041720013700.02396@idun>
2001-04-20 13:41     ` Disconnect
2001-04-17 19:21 ` H. Peter Anvin [this message]
2001-04-17 23:58   ` Albert D. Cahalan
2001-04-20 12:13   ` Stephen C. Tweedie
2001-04-20 14:23     ` Venkatesh Ramamurthy
2001-04-20 14:49       ` Alan Cox
2001-04-20 15:40         ` Venkatesh Ramamurthy
2001-04-20 18:51         ` Stephen C. Tweedie
2001-04-21 15:48           ` Rik van Riel

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='9bi53d$5n6$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.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.