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=-1.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id B78A22738F for ; Sun, 19 May 2024 04:28:24 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2497F43AB6; Sun, 19 May 2024 12:28:21 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1716085701; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=xP3yCBZuFkwTSU7g+f6IAV8cpWqREfC0JlH8P6MdeRY=; b=tn3FRkvrow/SSL8vPsZ5R3EKDq7U4JwrB3H/VC+EbBoogV2OZlDAzbsfuk2UMn6+vACdKY KD95Ys80pRWHFy+Kynn4tzDUUCAV9dxK+hUw4WeL4H+q6TXQredoxgesq5L3odfWOhcin+ er9wuV1PDjywnUUJoUWN9ztlrWN4THQ= Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by minnie.tuhs.org (Postfix) with ESMTPS id 7D72843AAB for ; Sun, 19 May 2024 12:28:15 +1000 (AEST) Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1eeb1a4c10aso45329895ad.3 for ; Sat, 18 May 2024 19:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1716085695; x=1716690495; darn=tuhs.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xP3yCBZuFkwTSU7g+f6IAV8cpWqREfC0JlH8P6MdeRY=; b=0nOhk0Ow4xo2LmByJhfskMy6agKcfngKrqw0YdJsFknTjWiEA+FMP8T6pPIUrk/ehy SIv4qi303EdXC78vNrMahwtbDQyNFG/0icXc5xfby8MzkDzpAxMX5/rD6qnoIwFafqkc F+vqBtSxZW9FnvdTjaDCO6/sQ9WEE/miRMyJYnHpHxqix1xtPih3swhTsYaXizVqmCQ6 JCqCki7HjDyqajvm8mtd/21NBkrSGY29EvgFf/TncQJhWZR9deeJPJ0OyLWEMhFPl8KJ bscKr2NcakucuHl9bKOPEbYcINmiG8gQjNbClFgU5p4SCjLhXDYnRyvLK2uQXgXtUliU JzfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716085695; x=1716690495; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xP3yCBZuFkwTSU7g+f6IAV8cpWqREfC0JlH8P6MdeRY=; b=L0V9yPjggPudNAzSzNgXFaw61fh9eKJqKkbZWWAPZgZcTliTDgtMoRRTRYppi1U/9w PJm9cmk3a2K5YVd+DDruIvGsMDRJMSp8rJPpBO3tMSsgxvIHjZ7VW9dBxxR+9Xpmuo6q 6DQl3x0rbeTGpyRmAfEmzDBkNfTkP6Ima/akMS5BWNdXY8rJLPGPYxgke9O/zLlwX64O xLt69qbyFhQNc/LGBjq4H2D9Az2R6nK87h8xYJ35tDQuhVX9nDpGefu9PnAloflH2HbQ cW8ydkVdjzOwlM9PhDnk0JXfcMQBYjC7QB58ZJFLYu6AElJ7kTv4MeByCfhkgt04thab dbzA== X-Gm-Message-State: AOJu0YxXc0s2+YxMsLi8x+DfFwZTmusDsrX9tO0QAyLAnvW4R+YbqpeF 3K5xoVQGRHofNwMmOZwOqRvpzG1CWdWHh11PoM3qcBinVxLF7BdyR9myWtmsxepkwM0MP+N9qgQ = X-Google-Smtp-Source: AGHT+IEV1LdNiABhhehiY8p6Wer4RhT6/TrTUR4jyPHhtHUkuBoyiZBoQLQbuJpZvbqHRww9r/70WA== X-Received: by 2002:a17:902:82c8:b0:1ec:5f1f:364f with SMTP id d9443c01a7336-1ef43d18196mr233716395ad.26.1716085694750; Sat, 18 May 2024 19:28:14 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f2f7e2de1dsm5104015ad.59.2024.05.18.19.28.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 May 2024 19:28:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) In-Reply-To: <20240519020256.GV9216@mcvoy.com> Date: Sat, 18 May 2024 19:28:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5216605C-37DD-4B39-9363-4DF9327FEEAB@iitbombay.org> 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> <20240519020256.GV9216@mcvoy.com> To: Larry McVoy X-Mailer: Apple Mail (2.3774.600.62) Message-ID-Hash: YBFZT6DZ6SHHFRCLMMZAYEDFKRCWKENP X-Message-ID-Hash: YBFZT6DZ6SHHFRCLMMZAYEDFKRCWKENP X-MailFrom: bakul@iitbombay.org 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: From: Bakul Shah via TUHS Reply-To: Bakul Shah X-Spam: Yes On May 18, 2024, at 7:02=E2=80=AFPM, Larry McVoy wrote: >=20 > On Sat, May 18, 2024 at 06:40:42PM -0700, Bakul Shah wrote: >> On May 18, 2024, at 6:21???PM, Larry McVoy wrote: >>>=20 >>> 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! >>>=20 >>> Do any micro kernels do address space to address space bcopy()? >>=20 >> mmapping the same page in two processes won't be hard but now >> you have complicated cat (or some iolib)! >=20 > 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. Two TLB entries can point to the same physical page. Is that not good enough? One process can give its address space a..b and the kernel (or the memory daemon) maps a..b to other process'es a'..b'. a..b may be associated with a file so any IO would have to be seen by both. > 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. >=20 > 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. You can sort of evolve plan9's rfork to do a partial address share. The issue with process vs thread is the context switch time. Sharing pages doesn't change that.=