From: Ralf Baechle <ralf@uni-koblenz.de>
To: "Eric W. Biederman" <ebiederm+eric@ccr.net>
Cc: James Simmons <jsimmons@edgeglobal.com>,
"Stephen C. Tweedie" <sct@redhat.com>,
"Benjamin C.R. LaHaise" <blah@kvack.org>,
Linux MM <linux-mm@kvack.org>
Subject: Re: page faults
Date: Tue, 26 Oct 1999 11:05:58 +0200 [thread overview]
Message-ID: <19991026110558.A1588@uni-koblenz.de> (raw)
In-Reply-To: <m1wvsc8ytq.fsf@flinx.hidden>
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/
next prev parent reply other threads:[~1999-10-26 9:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-21 16:31 James Simmons
1999-10-21 19:40 ` Benjamin C.R. LaHaise
1999-10-22 0:47 ` Wang Yong
1999-10-22 13:06 ` Stephen C. Tweedie
1999-10-22 14:59 ` James Simmons
1999-10-22 15:15 ` Benjamin C.R. LaHaise
1999-10-22 17:35 ` Stephen C. Tweedie
1999-10-22 23:31 ` James Simmons
1999-10-24 17:15 ` Eric W. Biederman
1999-10-25 17:27 ` William J. Earl
1999-10-26 13:50 ` Marcus Sundberg
1999-10-26 14:00 ` Eric W. Biederman
1999-10-26 15:11 ` James Simmons
1999-10-26 18:04 ` William J. Earl
1999-10-26 9:05 ` Ralf Baechle [this message]
1999-10-29 14:52 ` James Simmons
1999-11-01 11:57 ` Stephen C. Tweedie
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=19991026110558.A1588@uni-koblenz.de \
--to=ralf@uni-koblenz.de \
--cc=blah@kvack.org \
--cc=ebiederm+eric@ccr.net \
--cc=jsimmons@edgeglobal.com \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
/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