kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Page fault in kernel code
Date: Tue, 09 Sep 2014 11:51:44 -0400	[thread overview]
Message-ID: <39139.1410277904@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Tue, 09 Sep 2014 18:53:55 +0530." <CAJKgH8C1cgQmJFJSBsNWB_tK9yWHZUaEUyimvm60d-YOCFeD0Q@mail.gmail.com>

On Tue, 09 Sep 2014 18:53:55 +0530, Manavendra Nath Manav said:

> Why is it so? Why can't kernel mode code handle the page fault and reload
> the page from swap? Also, can page fault occur when kernel is executing in
> process context and/or interrupt context?

There's no inherent chiseled-in-stone rule that says "the operating systems
kernel may not page fault", and in fact many operating systems allow it. The
IBM OS/360 family, starting with VS/1 and MVS (as OS/360's MFT and MVT variants
ran on hardware that didn't do virtual memory) clear through Z/OS 40 years
later now all supported having part of their kernel be pageable.  I've worked
with several Unix variants that allowed parts of the kernel to be pageable.

But that's a design decision that adds little real benefit, especially on
today's large RAM systems - even a Raspberry Pi has enough memory that you
don't really need to worry about making the kernel pageable.

Cautionary tale:  I once had a UTX/32 system that had routines for recovery
from disk errors (in particular, recovering and forwarding of bad blocks to
spare blocks was done by the host, *not* the device), and supported having
about 1/3 of the kernel code be pageable (this was in 1985 or so, and a
Powernode/9080 with 16M of RAM was a *big* system, so being able to put 500K of
a 1.5M kernel out on disk was a big win for performance).  I'll let you think
about what sort of afternoon I had the day that we kept hitting an I/O error on
a bad block in the swap area (which quite reasonably paused all I/O to the
failing disk until the error recovery routine ran), while the block-forwarder
module was swapped out....

(And I've had to debug similar dork-ups in VS/1, VM/SP, and MUSIC as well.
Actually... hmm, yep.  I think I've seen every single OS I've worked with in 3
decades that supported paged kernel end up shooting itself in the foot because
the wrong thing was paged out at the wrong time. That stuff is *hard* to get
right...)

That sort of thing is why Linus decided Just Say No. ;)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140909/19b06859/attachment.bin 

  parent reply	other threads:[~2014-09-09 15:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJKgH8Df51ZL-BaN_zBmtP=2tjxh5po6KWdbR1Q7LwiR2DZzTg@mail.gmail.com>
2014-09-09 13:23 ` Page fault in kernel code Manavendra Nath Manav
2014-09-09 14:25   ` Greg KH
2014-09-09 15:51   ` Valdis.Kletnieks at vt.edu [this message]
2014-09-09 16:54   ` Jeff Haran
2014-09-10  9:15     ` Manavendra Nath Manav
2014-09-10 12:54       ` Valdis.Kletnieks at vt.edu
2014-09-10 14:52         ` Manavendra Nath Manav
2014-09-11 12:03           ` Leon Romanovsky
2014-09-11 14:19             ` Christoph Lameter
2014-09-11 14:53             ` Miles MH Chen
2014-09-11 15:26               ` Leon Romanovsky

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=39139.1410277904@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=kernelnewbies@lists.kernelnewbies.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).