From mboxrd@z Thu Jan 1 00:00:00 1970 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=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11025 invoked from network); 15 Dec 2022 08:03:41 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2022 08:03:41 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 093BE42479; Thu, 15 Dec 2022 18:03:04 +1000 (AEST) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 9EB8E42478 for ; Thu, 15 Dec 2022 18:03:00 +1000 (AEST) Received: by mail-ej1-f52.google.com with SMTP id x22so50324435ejs.11 for ; Thu, 15 Dec 2022 00:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=l6ynRZnnI/QDmW59ZwOLTglNLnW7ZjWqiL8eXbWyLSU=; b=nauteQ93932jHoL7Z4S3F50YzeeTw3BZARO4Z0Ux0oi68LP4OXY+W3xJ6LwZ1qa6cK +vHr8N67ZQpSqOGFozII40Eeb89YPy8NYdiFP+ojWcHTrnqqIEctgr4mfpony+4pJgvs IB6TOlJwTDcIV5b40mY7/JD2poH+Dln4cDx+N49rJGBRvdT22RGhwsudQvgEd93+vj8J XhWZpACQ63oeDKLcS5JKHbp/0L3HRvYtbXuhAXWecXL3vryKHAjLzx8ultTh6dLDeSUL knFtWZC+E7rRDjiHrOrAb78oso+CpfU9rIHy5AWi7ixy2b6SmaXBkTxE3Obv5AQRtB8M kvfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=l6ynRZnnI/QDmW59ZwOLTglNLnW7ZjWqiL8eXbWyLSU=; b=5aSh8a4m+isnMxwHinrIPA8mXsozefDIp8I8lvnPRqjDqi7pEUDVhrqKeykdP9/D4d tuDJ/SHCEjcYzhNpu4oDs6GlvgDPBc4L04MlR6PbtlG/l3F22oFFyeqeSDL3MUEZcta5 SyjP2ld1FQHQd56vdXYs3kAShRtJyUijCSWZ6Zv5pXRJFjGVrcbD/unniaeSGSqktgVG sxXD1UlVJrLZ9bOIXwB6/ym1k5I5Vur0TlJNMrhl1h6Xlhptbc+THxt5xADcTHZ/UbMa CSpqZtQ4WzfShDjHiCjTsJLeihLUNGzs5UfXCuZY+Q78jIJ1M6zcTOi4LaWKfAEq4OAA hCvA== X-Gm-Message-State: ANoB5pngDt2mPi0j2xKn6r45Yb0alb5gD1KgJUafhuibsWm3akHr8cbd q0ES4ABb3FH/KBisg2ZKjUrXWnXY40ms/pRfe0N35TyP X-Google-Smtp-Source: AA0mqf7W1VrYL0LMDOt8qZqUSq3DTfAKb++BoTLLngEVrvIKU2blq94ciAUy3iZXyXwUOH3+U8EgdyYDsOWTT/DWJf0= X-Received: by 2002:a17:906:54cf:b0:7ae:43f5:a2a3 with SMTP id c15-20020a17090654cf00b007ae43f5a2a3mr78702068ejp.595.1671091318248; Thu, 15 Dec 2022 00:01:58 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a17:907:767c:b0:7c1:4150:c763 with HTTP; Thu, 15 Dec 2022 00:01:56 -0800 (PST) In-Reply-To: <20221215025453.GY20511@mcvoy.com> References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <4A770CCE-2BC9-4DA7-B3D7-71AF9A23F79E@iitbombay.org> <20221215025453.GY20511@mcvoy.com> From: Andrew Warkentin Date: Thu, 15 Dec 2022 01:01:56 -0700 Message-ID: To: tuhs@tuhs.org Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: WSDYGWW4YDAHCWWTD5E6GWFUNYIZ22YT X-Message-ID-Hash: WSDYGWW4YDAHCWWTD5E6GWFUNYIZ22YT X-MailFrom: andreww591@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 12/14/22, Larry McVoy wrote: > Wasn't there some statement that QNX dropped some of these? Copy plus > context switch? > Yeah, QNX/L4-type IPC is usually just copying followed by a context switch. Some such kernels (like seL4) don't even have full message queues per endpoint (the scheduler queue sort of functions as an IPC queue). Mach IPC is slow because of stuff like permission checking, which I would assume involves iteration over a list of permitted threads. QNX/L4-type kernels usually either use constant-time permission checks (like the old "clans and chiefs" model used by L3 and early L4, or the more modern capability-oriented model used by seL4 and some others), or lack kernel permission checking entirely leaving it up to servers. Another issue is that Mach-type kernels don't have what is known as "direct process switching" AFAIK. When a synchronous message is sent on a QNX/L4-type kernel, the kernel immediately switches to the receiving process, bypassing the scheduler queue entirely, with the remainder of the sender's timeslice being given to the receiver (depending on the kernel, priorities may factor into this so it isn't always quite that simple though). Mach-like kernels often require the sender to wait for the kernel to decide to schedule the receiver based on the queue, and then once the reply is sent there's another wait for the kernel to again decide to schedule the sender again, which makes for rather poor performance. On 12/14/22, Bakul Shah wrote: > On Dec 11, 2022, at 7:09 PM, Andrew Warkentin wrote: >> >> It's not necessarily true that microkernels are significantly slower. > > uKernels are usually quite fast as they do so little. What can be slow > is emulating a Unix like OS on top due to context switches. For instance, > a user process doing read() will have the following context switches: > > userProc->uK->FileSystem->uK->diskDriver->uk->FileSysem->uK->userProc > > or worse (I didn't account for a few things). Because of this even some > uKernels run a few critical services + drivers in the supervisor mode. > But overall slowdown of such a unix emulation will very much depend on the > workload and also what kind of performance improvements you are willing to > try in a complex kernel vs same services running in user mode. Yeah, excessive vertical layering can be bad for performance. QNX normally follows a process-per-subsystem-instance architecture, so the chain is just: client -> (kernel) -> diskServer -> (kernel) -> client where the disk server includes the disk driver, partition table driver (if applicable), and disk filesystem. The VFS layer isn't even involved at all on reads, writes, and the like (it's pretty much only there to deal with operations that involve paths and not those that only involve FDs), whereas some other Unix-like microkernel OSes have it act as an intermediary on all FS operations. A lot of the time, protection domains correspond more to subsystem instances rather than layer instances, so there really isn't much harm in merging all layers of a subsystem into a single process for the sake of performance. When there is a benefit to separation of layers into different processes, it is possible to use tap-type drivers to allow running subsystem instances that only contain some of the layers (QNX doesn't do this AFAIK, but my OS will).