From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 44CB8278DB for ; Sun, 19 May 2024 04:03:08 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id D544343AA8; Sun, 19 May 2024 12:03:04 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 746D143AA7 for ; Sun, 19 May 2024 12:02:57 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id CDD4735E919; Sat, 18 May 2024 19:02:56 -0700 (PDT) Date: Sat, 18 May 2024 19:02:56 -0700 From: Larry McVoy To: Bakul Shah Message-ID: <20240519020256.GV9216@mcvoy.com> References: <20240514111032.2kotrrjjv772h5f4@illithid> <20240515164212.beswgy4h2nwvbdck@illithid> <8D556958-0C7F-43F3-8694-D7391E9D89DA@iitbombay.org> <20240519012114.GU9216@mcvoy.com> <767E78C5-E6E7-4CB5-889D-B4E0E5FBA085@iitbombay.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <767E78C5-E6E7-4CB5-889D-B4E0E5FBA085@iitbombay.org> User-Agent: Mutt/1.5.24 (2015-08-30) Message-ID-Hash: FWHL4L2KZRIDVROX5YKIAI4YHWYNMMQE X-Message-ID-Hash: FWHL4L2KZRIDVROX5YKIAI4YHWYNMMQE X-MailFrom: lm@mcvoy.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Unix Heritage Society mailing list X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: If forking is bad, how about buffering? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sat, May 18, 2024 at 06:40:42PM -0700, Bakul Shah wrote: > On May 18, 2024, at 6:21???PM, Larry McVoy wrote: > > > > On Sat, May 18, 2024 at 06:04:23PM -0700, Bakul Shah via TUHS wrote: > >> [1] This brings up a separate point: in a microkernel even a simple > >> thing like "foo | bar" would require a third process - a "pipe > >> service", to buffer up the output of foo! You may have reduced > >> the overhead of individual syscalls but you will have more of > >> cross-domain calls! > > > > Do any micro kernels do address space to address space bcopy()? > > mmapping the same page in two processes won't be hard but now > you have complicated cat (or some iolib)! I recall asking Linus if that could be done to save TLB entries, as in multiple processes map a portion of their address space (at the same virtual location) and then they all use the same TLB entries for that part of their address space. He said it couldn't be done because the process ID concept was hard wired into the TLB. I don't know if TLB tech has evolved such that a single process could have multiple "process" IDs associated with it in the TLB. I wanted it because if you could share part of your address space with another process, using the same TLB entries, then motivation for threads could go away (I've never been a threads fan but I acknowledge why you might need them). I was channeling Rob's "If you think you need threads, your processes are too fat". The idea of using processes instead of threads falls down when you consider TLB usage. And TLB usage, when you care about performance, is an issue. I could craft you some realistic benchmarks, mirroring real world work loads, that would kill the idea of replacing threads with processes unless they shared TLB entries. Think of a N-way threaded application, lots of address space used, that application uses all of the TLB. Now do that with N processes and your TLB is N times less effective. This was a conversation decades ago so maybe TLB tech now has solved this. I doubt it, if this was a solved problem I think every OS would say screw threads, just use processes and mmap(). The nice part of that model is you can choose what parts of your address space you want to share. That cuts out a HUGE swath of potential problems where another thread can go poke in a part of your address space that you don't want poked. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat