page faults

page faults

[James Simmons]

Quick question. If two processes are sharing the same memory but no page
fault has happened. THen process A causes a page fault. If process B tries
to access the page that process A already page fault will process B cause
another page fault. Or do page faults only happen once no matter how many
process access it. 

"We've all heard that a million monkeys banging on a million typewriters
 will eventually reproduce the entire works of Shakespeare. Now,
 thanks to the Internet, we know this is not true."

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Benjamin C.R. LaHaise]

On Thu, 21 Oct 1999, James Simmons wrote:

> Quick question. If two processes are sharing the same memory but no page
> fault has happened. THen process A causes a page fault. If process B tries
> to access the page that process A already page fault will process B cause
> another page fault. Or do page faults only happen once no matter how many
> process access it. 

Only the first time the page is accessed is there a fault to put the entry
into the page table, regardless of the processes sharing the page.  The
only time entries are removed from a process' page tables is on fork
(ie marking private pages read only so COW works), unmap or vmscan's page
reclaims.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Wang Yong]

the page fault is an interrupt and do_page_fault is the handler, so no other
page fault
will be received in do_page_fault. this is true for linux because it's not
preemptive.
if the page fault is caused by a write to a shared page, do_wp_page will be
called
to copy this page to a new page(copy on write).

"Benjamin C.R. LaHaise" wrote:

> On Thu, 21 Oct 1999, James Simmons wrote:
>
> > Quick question. If two processes are sharing the same memory but no page
> > fault has happened. THen process A causes a page fault. If process B tries
> > to access the page that process A already page fault will process B cause
> > another page fault. Or do page faults only happen once no matter how many
> > process access it.
>
> Only the first time the page is accessed is there a fault to put the entry
> into the page table, regardless of the processes sharing the page.  The
> only time entries are removed from a process' page tables is on fork
> (ie marking private pages read only so COW works), unmap or vmscan's page
> reclaims.
>
>                 -ben
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://humbolt.geo.uu.nl/Linux-MM/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Stephen C. Tweedie]

Hi,

On Thu, 21 Oct 1999 15:40:15 -0400 (EDT), "Benjamin C.R. LaHaise"
<blah@kvack.org> said:

> On Thu, 21 Oct 1999, James Simmons wrote:
>> Quick question. If two processes are sharing the same memory but no page
>> fault has happened. THen process A causes a page fault. If process B tries
>> to access the page that process A already page fault will process B cause
>> another page fault. Or do page faults only happen once no matter how many
>> process access it. 

> Only the first time the page is accessed is there a fault to put the entry
> into the page table, regardless of the processes sharing the page.  

No.  If a process mmap()s a file and forks, then the two processes will
page fault independently.  Similarly if two separate processes mmap()
the same file, they will page fault independently.  Finally, if a
process has a data page which becomes faulted out and the process forks,
then the two resuling processes will both have to take independent page
faults to map the page.

However, there will only ever be one major fault (ie. one fault which
has to bring data in from disk).  If multiple processes share the same
page, then the second and all subsequent processes to fault on that page
will take a minor page fault which will just find the existing page in
memory and map that into the faulting process's page tables.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[James Simmons]

On Fri, 22 Oct 1999, Stephen C. Tweedie wrote:

> Hi,
> 
> On Thu, 21 Oct 1999 15:40:15 -0400 (EDT), "Benjamin C.R. LaHaise"
> <blah@kvack.org> said:
> 
> > On Thu, 21 Oct 1999, James Simmons wrote:
> >> Quick question. If two processes are sharing the same memory but no page
> >> fault has happened. THen process A causes a page fault. If process B tries
> >> to access the page that process A already page fault will process B cause
> >> another page fault. Or do page faults only happen once no matter how many
> >> process access it. 
> 
> > Only the first time the page is accessed is there a fault to put the entry
> > into the page table, regardless of the processes sharing the page.  
> 
> No.  If a process mmap()s a file and forks, then the two processes will
> page fault independently.  Similarly if two separate processes mmap()
> the same file, they will page fault independently.  Finally, if a
> process has a data page which becomes faulted out and the process forks,
> then the two resuling processes will both have to take independent page
> faults to map the page.
> 
> However, there will only ever be one major fault (ie. one fault which
> has to bring data in from disk).  If multiple processes share the same
> page, then the second and all subsequent processes to fault on that page
> will take a minor page fault which will just find the existing page in
> memory and map that into the faulting process's page tables.

Thank you for that answer. I remember you told me that threads under linux
is defined as two processes sharing the same memory. So when a minor
page fault happens by anyone one process will both process page tables get
updated? Or does the other process will have a minor page itself
independent of the other process? 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Benjamin C.R. LaHaise]

On Fri, 22 Oct 1999, James Simmons wrote:

> Thank you for that answer. I remember you told me that threads under linux
> is defined as two processes sharing the same memory. So when a minor
> page fault happens by anyone one process will both process page tables get
> updated? Or does the other process will have a minor page itself
> independent of the other process? 

Threads share the same page tables, hence the same memory.  The other task
might end up with a minor fault, but after it aquires the semaphore, it
will discover the pte is already freshly faulted in.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Stephen C. Tweedie]

Hi,

On Fri, 22 Oct 1999 10:59:25 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> Thank you for that answer. I remember you told me that threads under
> linux is defined as two processes sharing the same memory. So when a
> minor page fault happens by anyone one process will both process page
> tables get updated? Or does the other process will have a minor page
> itself independent of the other process?

Threads are a special case: there is only one set of page tables, and
the pte will only be faulted in once.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[James Simmons]

On Fri, 22 Oct 1999, Stephen C. Tweedie wrote:

> Hi,
> 
> On Fri, 22 Oct 1999 10:59:25 -0400 (EDT), James Simmons
> <jsimmons@edgeglobal.com> said:
> 
> > Thank you for that answer. I remember you told me that threads under
> > linux is defined as two processes sharing the same memory. So when a
> > minor page fault happens by anyone one process will both process page
> > tables get updated? Or does the other process will have a minor page
> > itself independent of the other process?
> 
> Threads are a special case: there is only one set of page tables, and
> the pte will only be faulted in once.


Does this mean that linux/drivers/sgi/char/graphics.c page fault handler
not work for a threaded program? It works great switching between
different processes but if this is the case for threads this could be a
problem.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Eric W. Biederman]

James Simmons <jsimmons@edgeglobal.com> writes:

> On Fri, 22 Oct 1999, Stephen C. Tweedie wrote:
> 
> > Hi,
> > 
> > On Fri, 22 Oct 1999 10:59:25 -0400 (EDT), James Simmons
> > <jsimmons@edgeglobal.com> said:
> > 
> > > Thank you for that answer. I remember you told me that threads under
> > > linux is defined as two processes sharing the same memory. So when a
> > > minor page fault happens by anyone one process will both process page
> > > tables get updated? Or does the other process will have a minor page
> > > itself independent of the other process?
> > 
> > Threads are a special case: there is only one set of page tables, and
> > the pte will only be faulted in once.
> 
> 
> Does this mean that linux/drivers/sgi/char/graphics.c page fault handler
> not work for a threaded program? It works great switching between
> different processes but if this is the case for threads this could be a
> problem.

It means it may not work as intended.
Once the page is faulted in all threads will have access to it.

If the hardware cannot support two processors hitting the region simultaneously,
(support would be worst case the graphics would look strange)
you could have problems.

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[William J. Earl]

Eric W. Biederman writes:
...
 > If the hardware cannot support two processors hitting the region simultaneously,
 > (support would be worst case the graphics would look strange)
 > you could have problems.
...
      One could reasonably take the view that a threads-aware graphics library
should be thread-safe.  That is, if the hardware needs to have concurrent
threads in a single process serialize access to the hardware, then the 
library plugin for that hardware should do the required serialization.

      This of course the neglects the question of whether a broken
user-mode program could damage the hardware, but then a broken
single-threaded user-mode program, with no other programs using the
hardware, could just as easily damage the hardware.  That is, if the
hardware is not safe for direct access in general, threading does not
make it any less safe.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Ralf Baechle]

On Sun, Oct 24, 1999 at 12:15:29PM -0500, Eric W. Biederman wrote:

> > Does this mean that linux/drivers/sgi/char/graphics.c page fault handler
> > not work for a threaded program? It works great switching between
> > different processes but if this is the case for threads this could be a
> > problem.
> 
> It means it may not work as intended.
> Once the page is faulted in all threads will have access to it.

This interface is inherited from IRIX where it is used for the X server
and other direct rendering programs.  It probably even predates the
IRIX sproc(2) interface for kernel threads.  And sproc(2) again has the
advantage that it allows for thread-local mappings.  So for example
IRIX threads always have their PRDA mapped locally and can have their
stacks all at the same address because the stack area is mapped only
locally.

In the past Linus already said that he doesn't want such a feature to
enter mm and I agree with him because of the involved complexity.  So
in short I'd say it's best to leave the operation of this interface
undefined and recommend the usage of a separate rendering thread or
a suitable mutual exclusion algorithem.

> If the hardware cannot support two processors hitting the region
> simultaneously, (support would be worst case the graphics would look
> strange) you could have problems.

I'm sure there is stupid hardware which will allow to crash the system.

  Ralf
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Marcus Sundberg]

"William J. Earl" <wje@cthulhu.engr.sgi.com> writes:

> Eric W. Biederman writes:
> ...
>  > If the hardware cannot support two processors hitting the region simultaneously,
>  > (support would be worst case the graphics would look strange)
>  > you could have problems.
> ...
>       One could reasonably take the view that a threads-aware graphics library
> should be thread-safe.  That is, if the hardware needs to have concurrent
> threads in a single process serialize access to the hardware, then the 
> library plugin for that hardware should do the required serialization.
> 
>       This of course the neglects the question of whether a broken
> user-mode program could damage the hardware, but then a broken
> single-threaded user-mode program, with no other programs using the
> hardware, could just as easily damage the hardware.  That is, if the
> hardware is not safe for direct access in general, threading does not
> make it any less safe.

The hardware _is_ safe for direct access, but _not_ while the
accelerator is running.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Eric W. Biederman]

"William J. Earl" <wje@cthulhu.engr.sgi.com> writes:

> Eric W. Biederman writes:
> ...
>  > If the hardware cannot support two processors hitting the region simultaneously,
>  > (support would be worst case the graphics would look strange)
>  > you could have problems.
> ...
>       One could reasonably take the view that a threads-aware graphics library
> should be thread-safe.  That is, if the hardware needs to have concurrent
> threads in a single process serialize access to the hardware, then the 
> library plugin for that hardware should do the required serialization.
> 
>       This of course the neglects the question of whether a broken
> user-mode program could damage the hardware, but then a broken
> single-threaded user-mode program, with no other programs using the
> hardware, could just as easily damage the hardware.  That is, if the
> hardware is not safe for direct access in general, threading does not
> make it any less safe.

Except on logically ``single thread'' hardware. Which I have heard exists.
Where the breakage point is simple writers hitting the harware at the
same time.

And since James work seems to have been how to protect the world from
broken hardware. . .

Also for the sgi hardware the design I believe is with the kernel
doing all of the thread/porocess synchronization by mapping/unmapping
the hardware.  That technique does not work on linux.

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[James Simmons]

On 26 Oct 1999, Eric W. Biederman wrote:

> "William J. Earl" <wje@cthulhu.engr.sgi.com> writes:
> 
> > Eric W. Biederman writes:
> > ...
> >  > If the hardware cannot support two processors hitting the region simultaneously,
> >  > (support would be worst case the graphics would look strange)
> >  > you could have problems.
> > ...
> >       One could reasonably take the view that a threads-aware graphics library
> > should be thread-safe.  That is, if the hardware needs to have concurrent
> > threads in a single process serialize access to the hardware, then the 
> > library plugin for that hardware should do the required serialization.

This would require a rewrite of opengl since opengl is heavly threaded.
Yes in IRIX all processes and threads have have their own private
mappings. This is what makes the direct engine work under threaded apps
and non threaded apps for IRIX. Of course linux having shared mapping
between threads does present a barrier. Nothing that can't be solved :) 

> >       This of course the neglects the question of whether a broken
> > user-mode program could damage the hardware, but then a broken
> > single-threaded user-mode program, with no other programs using the
> > hardware, could just as easily damage the hardware.  That is, if the
> > hardware is not safe for direct access in general, threading does not
> > make it any less safe.
> 
> Except on logically ``single thread'' hardware. Which I have heard exists.
> Where the breakage point is simple writers hitting the harware at the
> same time.
> 
> And since James work seems to have been how to protect the world from
> broken hardware. . .

Since I'm talking about sgi machines here there doesn't exist a broken
hardware problem. Even with this case SGI ensures non simultaneous access
to the hardware by different processes. The reason being is the point of
/dev/gfx on SGI is to properly virtualize the graphics engine. This means 
that from the point of each process that process believes it has sole
access to the graphics engine and its does for the time slice of the
current process. Allowing two threads similtaneous access defeats the
whole point of virtualization. If you don't want to virtualize the accel
engine of any cards then you are better off writing just userland
libraries to handle this. Of course you have to put up with the headaches
of making sure all userland code using the accel engine talk to each other
so they don't step on each other toes (ie cooperative locking). Virtuialization
is my most important goal. If you have proper virtuailization then access
to broken hardware is not a problem then. Except in the case where the
hardware mapps dangerous registers with the accel registers to userland. 

> Also for the sgi hardware the design I believe is with the kernel
> doing all of the thread/porocess synchronization by mapping/unmapping
> the hardware.  That technique does not work on linux.

For linux yes the approach is to use the page fault handler to test to see
if a different process already has this mapping. If this is the case
revoke that mapping. Then map that into the current process address
space. See linux/drivers/sgi/char/graphics.c sgi_graphics_nopage to see
what I mean. IRIX does it differently. It truly virtualizes the graphics
engine. To the point where you don't need coperative locking. It
uses a schedular *HOOK* and the page fault handler to manage proper
virtualization. Lets give a few examples of what actually happens. Let
start with one app using the graphics engine. It causes a page fault and 
on the page fault locks the accel engine with a semaphore. Thus you only
have the cost at page fault time instead of unlocking and locking before
each MMIO region access. Now a second process wants to use the accel
engine while the first is using it. It faults and queues up on a
semaphore, and the next time the first process context switches, it
releases access to the graphics engine and the second process gets it's
mapping validated. The next time the first process resumes, the scheduling
hook make sure that the process doesn't have a valid mapping so that it
will fault the next time its tries to access the graphics engine. So this
is how IRIX does it. It does it quit well even on their monster machines
with 128 CPUs and 16 video cards. Now you are asking is the schedular
hook really needed. If you have a process that locks the MMIO regions
then does a sleep(60) you can't have it blocking all the other processes 
waiting for the graphcis engine. Now don't think is hook is a big
massive rewrite of the scehdular. It knows nothing about graphics
hardware. All it does is call a specific driver function if it needs
to. I know some people would go nuts seeing something about a
schedular change. Even a small one like this. This is the technique I
would like seen ported to linux.       




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[William J. Earl]

Eric W. Biederman writes:
 > "William J. Earl" <wje@cthulhu.engr.sgi.com> writes:
...
 > >       This of course the neglects the question of whether a broken
 > > user-mode program could damage the hardware, but then a broken
 > > single-threaded user-mode program, with no other programs using the
 > > hardware, could just as easily damage the hardware.  That is, if the
 > > hardware is not safe for direct access in general, threading does not
 > > make it any less safe.
 > 
 > Except on logically ``single thread'' hardware. Which I have heard exists.
 > Where the breakage point is simple writers hitting the harware at the
 > same time.
 > 
 > And since James work seems to have been how to protect the world from
 > broken hardware. . .

       Threading cannot make this more hazardous.  Suppose two threads, A and B,
accessing the hardware concurrently, were each to do a series of instructions
I[i].  Suppose these instructions were interleaved:

       I[0]-A
       I[0]-B
       I[1]-A
       I[1]-B
       I[2]-A
       I[2]-B
       ...

and that this broke the hardware.  Then suppose that, instead, 
thread A simply executed a series of instructions with same effect
on the hardware as the above series of instructions (with thread B
not executing at all).  Then a single thread would damage the hardware.
That is, if some series of user-mode instructions can damage the hardware,
then broken threaded programs (where "broken" includes not adequately
serializing their operations) are no more or less hazardous than
a broken single threaded program.  If you rely on correct user-mode code
(neglecting threading), then you are always at risk of having a broken
application damage the hardware.

 > Also for the sgi hardware the design I believe is with the kernel
 > doing all of the thread/porocess synchronization by mapping/unmapping
 > the hardware.  That technique does not work on linux.

     That is the way IRIX handles the hardware.  It is not trivially
implementable on Linux.  The more important point is that SGI hardware
can be context-switched.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[James Simmons]

> In the past Linus already said that he doesn't want such a feature to
> enter mm and I agree with him because of the involved complexity.  So
> in short I'd say it's best to leave the operation of this interface
> undefined and recommend the usage of a separate rendering thread or
> a suitable mutual exclusion algorithem.

I agree too. I will see which is better. A mutal exclusion algorithm or a
special graphics thread which does have its own private mappings.

> > If the hardware cannot support two processors hitting the region
> > simultaneously, (support would be worst case the graphics would look
> > strange) you could have problems.
> 
> I'm sure there is stupid hardware which will allow to crash the system.

Its about proper virtualization. Imagine if userland would have to
negotate access to hard drives. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: page faults

[Stephen C. Tweedie]

Hi,

On Fri, 29 Oct 1999 10:52:57 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> Its about proper virtualization. Imagine if userland would have to
> negotate access to hard drives. 

As soon as you start to memory map the files, it does.  The kernel has
no business enforcing user-level transactions to virtual memory.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/