From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: dbailey27@ameritech.net Cc: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel In-Reply-To: <0374a3982e4b359e09ce2a3be9192f06@yourdomain.dom> Message-ID: References: <0374a3982e4b359e09ce2a3be9192f06@yourdomain.dom> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 26 Feb 2004 23:47:30 -0800 Topicbox-Message-UUID: fda10a04-eacc-11e9-9e20-41e7f4b1d025 On Fri, 27 Feb 2004 dbailey27@ameritech.net wrote: > > Okay, but is there a reason why it *needs* to be on the stack? What's the > rationale behind this usage. The rationale is that it's incredibly more sane, and it's the logical place to put something that (a) needs to be allocated thread-specific and (b) doesn't need any special allocator. In short, it's an automatic variable. You are arguing against automatic variables in C. You apparently do so for some incredibly broken religious reason, and hey, I simply don't care. > Well, I'm hoping to determine what really is the best thing for OS design, > as a whole. I can guarantee you that the broken behaviour of SGI sproc and plan-9 rfork i sa major pain in the ass for VM management. I'm obviously very biased, but I claim that the Linux VM is the best VM out there. Bar none. It's flexible, it's clearly very portable to every single relevant hardware base out there (and quite a few that aren't relevant), and it's efficient. And at the same thing, the Linux VM (from an architecture standpoint) is simple. There are lots of fundamentally hard problems in teh VM stuff, but they tend to be things that _are_ fundamentally hard for other reasons (ie page replacement algorithms in the presense of many different caches that all fight for memory). But the actual virtual mapping side is very simple indeed. And the plan-9/irix thing isn't. It's an abomination. And there are real _technical_ reasons why it's an abomination: - it means that you cannot share hardware page tables between threads unless you have special hardware (ie it is either fundamentally unportable, or it is fundamentally inefficient) - it means that you have to give different TLB contexts to threads, causing inefficient TLB usage. See above. - it means that you need to keep track of separate lists of "shared" and "private" VM mapping lists, and locking of your VM data structures is a complete nightmare. - it almost certainly means a lot of special cases, since on the magic hardware that does have segmented page tables and where you want to share the right segments, you now have magic hardware-dependent limits for which areas can be shared and which can be private. But yes, I'm biased. Linus