Re: [9fans] Current status of amd64 port?

[Charles Forsyth <forsyth@terzarima.net>]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

no, i meant that on a page fault, fault.c just does much the same
read from the file that the system call would do, except it's more complicated to get there.
		ask = s->flen-soff;
		if(ask > BY2PG)
			ask = BY2PG;

		n = devtab[c->type]->read(c, kaddr, ask, daddr);
		if(n != ask)
			faulterror(Eioload, c, 0);

(and that's also true on SunOS, Solaris, and probably Linux, except that on some
it is really very complicated, not just more complicated than read.)
the thing that saves it is the Image cache off to the side.

[-- Attachment #2: Type: message/rfc822, Size: 4203 bytes --]

From: "ron minnich" <rminnich@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Current status of amd64 port?
Date: Fri, 16 Nov 2007 15:38:17 -0800
Message-ID: <13426df10711161538q2b4fda69q1f37afbcaffecc74@mail.gmail.com>

On Nov 16, 2007 3:40 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> > that's a good question.  i suppose you could argue not since
> > a plan 9 kernel could get by without demand paging, it's just
> > one of the kernel's dirty little secrets.
>
> it isn't really mmap'd as such: it does a read from a file into memory
> so (as is usually the case on systems with mmap) it's quicker just to do
> the read yourself, rather than suffer the page fault too.

Well, I don't know Charles. When I was watching the page faults in the
ports I did, the first page fault was for address 0x1020, first
address in executable. I had assumed this was a demand paging case,
now you are going to force me to go look :-)

ron