Messages in this thread | | | Date | Tue, 14 Dec 1999 09:42:00 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 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/
| |