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,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24976 invoked from network); 16 Sep 2021 18:40:02 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 Sep 2021 18:40:02 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2C9489CABE; Fri, 17 Sep 2021 04:39:58 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id CE2EC9CAB3; Fri, 17 Sep 2021 04:39:20 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="abKA6Vtu"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B30B29CAB3; Fri, 17 Sep 2021 04:39:16 +1000 (AEST) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by minnie.tuhs.org (Postfix) with ESMTPS id CB5729CAB2 for ; Fri, 17 Sep 2021 04:39:15 +1000 (AEST) Received: by mail-ot1-f42.google.com with SMTP id q11-20020a9d4b0b000000b0051acbdb2869so9562485otf.2 for ; Thu, 16 Sep 2021 11:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Qe2v9SOnNhekUyT600yiAeru+JOsBwid9l2oeRvgkVo=; b=abKA6VtuJtV8yAntcDyRe0AjyFMm136LDgPXEJF7XrWbmUdlpi7+K49SfIxYPsi+t3 NgogccQVyu0d5ABQeymnFOhIx+uc8SlA4ICnQ2DGB/Lk0cwxdygmNNC0uIsSWqfGelVs chTEUGacsK6cEDaog1dssO98Z9ze8MB+cwgoOR3WNfnHShXSn/2D9j2JftKHM4LN84zO vbqinBUAAM4urVYpRPO5vJNoDFiyuRighqhMaQP+WnpR7HLjDrYXtR3cbdvfco4Jc13R v90JXdHZ3zDwDScKTNH0IdpKWMtleYttAZyPoF92332mOaAlcNez3uZewbyNXgwTNAcJ uA9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Qe2v9SOnNhekUyT600yiAeru+JOsBwid9l2oeRvgkVo=; b=NwWiIjOaXxthnxvnyahyXg3rrCVcjOIbLQObC2mDzSCDVvxPY0EB7TSXQomNTdwSLZ 2PsX0odOzy4XbPce/crqo//LTj83HLkmwVQuppCDrGVZrBrUe08bHRIPr8LQTVO4b8Ft WjTpozaWwN0DVY37MzywGMQVs6otI9VOtWeGUyXSFONSNga0vA4QWK/davStGHkCm52C /cdUG2rtxCLzMzZVATS6qyOC0i3x32uVjW3k9v/6nuHRwkx9nyF656XrywcMMhxFl5U9 LaAx/+dPQUAAsrhiGLWShTwk0VgFex7WdG2DFo2/8tcqnnAUIFSxkA+khUY1RTZJEeyS X4hA== X-Gm-Message-State: AOAM532JuVf5s5AykjCtr1qAthdXb2ZjUeJH1fQ+ziKFA1nGvhv63ALG vKFPMPL4Smkev8UYjvMc1nHsvEUa/bYZGIVk4ZO38Rgc X-Google-Smtp-Source: ABdhPJz+wURoHTcoSyNszgDqoYaGTdUTAbQ4hmllQ+JPDLUS6zzHtsfg5K50b3EEgjYKnIm8hwKy45zxNVBe6pONcKY= X-Received: by 2002:a05:6830:831:: with SMTP id t17mr5894569ots.225.1631817554696; Thu, 16 Sep 2021 11:39:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Cross Date: Thu, 16 Sep 2021 14:38:38 -0400 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="000000000000af9ca905cc212177" Subject: Re: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000af9ca905cc212177 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 1, 2021 at 5:58 PM Dan Cross wrote: > [snip] > First, thank you for all of the thoughtful responses, both on-list and off. An interesting theme in many of the responses was essentially questioning whether the underlying OS still matters, since the focus on development has shifted to higher levels? E.g., we now provision components of our enormously large and complicated distributed applications with building blocks like containers, less physical machines, let alone processes etc. That is certainly a trend, but it strikes me that those containers have to run somewhere, and at some point, we've still got instructions executing on some CPU, modifying words of memory, registers, etc; presumably all of that runs under the control of an operating system. It is a worthwhile question to ask whether that operating system still matters at all: what we have works, and since it's so hidden behind layers upon layers of abstraction, do we really care what it is? But I claim that it does perhaps more than most folks realize. Certainly, there are metrics that people care about (tail latency, jitter, efficiency at the 90th, 95th, 99th percentile...) and OS effects can have outsized impacts there; Mothy's talk alludes to this when he talks about all of the hidden processing that's happening all over a modern computer, eventually some of that trickles onto the cores that are running one's containerized Node application or whatever (lookin' at you, SMM mode...). At the end of the day, the code we care about still runs in some process under some OS on some bit of physical hardware, regardless of all of the abstractions we've placed on top of those things. What that system does, and the abstractions that its interface provides to programs, still matters. Perhaps another question worth asking is, does it make sense to look at different models for those systems? My subjective impression is that, back in the 60s and 70s, there was much greater variation in system architectures than today. A common explanation for this is that we didn't know how to build systems at the time, so folks threw a lot of stuff at the wall to see what would stick. But we no longer do that...again, Mothy alludes to this in his brief survey of OSDI papers: basically, new systems aren't being presented. Rob Pike also lamented that state of affairs 20 years ago, so it's been going on for a while. Does that mean that we've come up with a recipe for systems that work and work well, and therefore we don't need to rethink those basic building blocks? Or does that mean that we're so used to our systems working well enough that we've become myopic about their architecture, and thus blind to their faults? - Dan C. --000000000000af9ca905cc212177 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 1, 2021 at 5:58 PM Dan Cross <= crossd@gmail.com&= gt; wrote:
[snip]

First, = thank you for all of the thoughtful responses, both on-list and off.
<= div>
An interesting theme in many of the responses was essent= ially questioning whether the underlying OS still matters, since the focus = on development=C2=A0has shifted to higher levels? E.g., we now provision co= mponents of our enormously large and complicated distributed applications w= ith building=C2=A0blocks like containers, less physical machines, let alone= processes etc. That is certainly a trend, but it strikes me that those con= tainers have to run somewhere, and at some point, we've still got instr= uctions executing on some CPU, modifying words of memory, registers, etc; p= resumably all of that runs under the control of an operating system.
<= div>
It is a worthwhile question to ask whether that operatin= g=C2=A0system still matters at all: what we have works, and since it's = so hidden behind layers upon layers of abstraction, do we really care what = it is? But I claim that it does perhaps more than most folks realize. Certa= inly, there are metrics that people care about (tail latency, jitter, effic= iency at the 90th, 95th, 99th percentile...) and OS effects can have outsiz= ed impacts there; Mothy's talk alludes to this when he talks about all = of the hidden processing that's happening all over a modern computer, e= ventually some of that trickles onto the cores that are running one's c= ontainerized Node application or whatever (lookin' at you, SMM mode...)= . At the end of the day, the code we care about still runs in some process = under some OS on some bit of physical hardware, regardless of all of the ab= stractions we've placed on top of those things. What that system does, = and the abstractions that its interface provides to programs, still matters= .

Perhaps another question worth asking is, does i= t make sense to look at different models for those systems? My subjective i= mpression is that, back in the 60s and 70s, there was much greater variatio= n in system architectures than today. A common explanation for this is that= we didn't know how to build systems at the time,=C2=A0so folks threw a= lot of stuff at the wall to see what would stick. But we no longer do that= ...again, Mothy alludes to this in his brief survey of OSDI papers: basical= ly, new systems aren't being presented. Rob Pike also lamented that sta= te of affairs 20 years ago,=C2=A0so it's been going on for a while. Doe= s that mean that we've come up with a recipe for systems that work and = work well, and therefore we don't need to rethink those basic building = blocks? Or does that mean that we're so used to our systems working wel= l enough that we've become myopic about their architecture,=C2=A0and th= us blind to their faults?

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 - Dan C.

--000000000000af9ca905cc212177--