lkml.org 
[lkml]   [1999]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread-private mappings and graphics (was Re: Per-Processor Data Page)


On Tue, 14 Dec 1999, James Simmons wrote:
> >
> > I'm suprised an SGI person hasn't learnt from past mistakes. IRIX is
> > unstable, and unmaintainable, and please just face it - it's because SGI
> > had the "cool feature of the day" disease.
>
> Because IRIX has certain design flaws doesn't mean the entire OS is
> crap. I have heard nothing but good things about XFS.

I'm not claiming that Irix is _bad_.

I _am_ claiming that it has had certain features, especially wrt graphics,
added without much thought for a "design".

The thing that makes me admire UNIX is not that it's UNIX. The thing I
like about UNIX is that even after 30 years, the fundamentals stand out.
The basic notion of files as unstructured streams of data, and the UNIX
fork/exec way of doing things (most everybody else does a "spawn()", which
does not have the same philosophy at all).

And quite frankly, especially when it comes to threads, Linux has a
DESIGN. It's not the hodge-podge of threading issues that we call
"pthreads" that came about from different vendors tryign to solve the same
problem in different ways (inluding user-mode only solutions). It's a
CONCEPT, the same way "fork()" is a concept.

The difference between a "concept" and a "random collection of routines"
is that the concept will survive, and the routines won't.

But that also requires that people don't mess up the concept by thinking
that it's "just an implementation". Because once lost, you won't be able
to undo the changes. You can fix bugs, but you can't easily remove the
"feature of the day".

> I'm not talking about implementing Thread-private mappings for the
> entire system. What I have done is when the process mmaps the accel region
> set a flag. This way if the process creates new threads or forks it will
> have a private mapping. The impact of private mapping is thus minimized.

Wrong.

Just because you think normal people won't use it desn't mean that the
impact is "minimized".

You've broken the concept of shared TLB's. You've then superglued the
broken parts together and said "if you look at it from the right angle you
cannot SEE the cracks".

But the cracks ARE THERE! They make the system more complex internally,
and even when you don't see the cracks you may notice that the thing
doesn't quite stand up straight.

You broke the whole notion of interchangeable, anonymous, shared TLB
mappings.

You broke the notion that when a thread is switched, no MM work needs to
be done.

You broke the notion that you can simply look at "process->mm" and
determine whether it can share the TLB state with another thread (even if
that TLB state in between was used by an anonymous kernel thread).

In short, you took a notion and dirtied it until it was just a random
collection of routines that superficially LOOK like it has a design.

In short, you didn't care about the BEAUTY.

> threads use the accel region. I just don't see that happening. Also how
> many threads will a well designed OpenGL library have. You don't want to
> go crazy here creating a bunch of threads.

Oh, no. I suspect most things that use OpenGL won't be all that much
threaded at all.

> The question we have to ask why do we want private mapping.

No. You're asking the WRONG question.

There is no way in HELL we want private mappings. End of story.

Use processes and SysV shared memory if that is what you're after.It works
today, and it gets you EXACTLY the same semantics that you are apparently
after. Sure, you have to think about the problem another way, but it's
just a mirror image.

Instead of saying "ok, I want private mappings in a shared address space",
you say "ok, I want shared mappings in private address spaces".

What's the difference? Doesn't soundlike much, no?

But look at it from a NOTIONAL standpoint. You don't break anything by
taking a private address space and adding a shared object to it - we've
had that notion for a long time, and then you HAVE a private TLB and a
private page table to play with.

In contrast, if you break the sharedness of a shared address space, YOU
DON'T HAVE ANYTHING LEFT! You just broke the bubble, and it popped. You
turned it into a private address space, for no gain (you already HAD
private address spaces, so you just degenerated the whole system).

> The reason
> DRE (Direct Rendering Engine) needs this is to ensure a page fault
> happens.

No. Add a pointer to the mapping in the graphics context, and you can do
the same thing. Each graphics context gets associated with the particular
mapping you have.

Or do graphics contexts by hand, without depending on page faults. Have a
lock.

I'm not asking you. I'm TELLING you that your idea will not be accepted in
the standard kernel. I can go on explaining all day WHY, but you don't
seem to care. You're ignoring the bigger picture, and that's your right.
It's also your right to f*ck up your own version of Linux, but you're not
getting close to mine.

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [from the cache]
©2003-2011 Jasper Spaans