The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Larry McVoy <lm@mcvoy.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe)
Date: Sun, 19 Sep 2021 00:05:25 -0400	[thread overview]
Message-ID: <YUa3BUjRH7IAzcEL@mit.edu> (raw)
In-Reply-To: <20210917221149.GC3365@mcvoy.com>

On Fri, Sep 17, 2021 at 03:11:49PM -0700, Larry McVoy wrote:
> > I'd suggest that is not Apple, but ARM.  That was sort of the whole
> > point of their BIG.little architecture with performance and efficiency
> > cores.
> 
> Credit to ARM, but M1 was where I saw it first.  The M1 performance is
> pretty impressive as well.  Reminds me of LED bulbs: "Wait, these are
> brighter, use less power, and cost less?  How is that a thing?"

ARM's BIG.little architecture dates back to 2011.  Of course, they
didn't *tell* anyone that they were doing this when before the chip
was released, lest it get copied by their competitors.  So they
released a hacked-up version of the Linux kernel that supported their
chip.  And successive versions of BIG.little implemented by different
ARM vendors had their own vendor-specific tweaks, with "board support
kernels" that were heavily hacked up Linux kernels in code that was
never sent upstream, since by the time vendors had released that chip,
their kernel team was moved to working on a new project, where they
would fork the current kernel version, and add completely different
hacks for the next year's version of their System on a Chip (SOC).

Proper support for differntly sized/powered cores didn't land in theb
ppstream Linux until 2019, when Linux 5.0 finally acquired support for
"Energy Aware Scheduling".

So not only does hardware engineering take longer, but it's done in
Sekrit, by software teams employed by chip manufacturers who often
don't have any long-time attachment to the OS, and who will get
reassigned to work the next year's SOC as soon as the current year's
SOC is released.  :-(

Things have gotten a bit better in the last five years, but that's a
pretty low bar, considering how horrible things were before that!

						- Ted

  reply	other threads:[~2021-09-19  4:06 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 21:58 Dan Cross
2021-09-02  8:42 ` Tony Finch
2021-09-03  0:19   ` John Cowan
2021-09-03  3:24     ` Douglas McIlroy
2021-09-03 13:21       ` Theodore Ts'o
2021-09-08 11:14         ` Tony Finch
2021-09-16 19:27         ` Dan Cross
2021-09-17  0:34           ` Theodore Ts'o
2021-09-17  0:44             ` Larry McVoy
2021-09-17 17:07               ` Bakul Shah
2021-09-17  1:33             ` Dan Cross
2021-09-02 15:41 ` Kevin Bowling
2021-09-02 20:12   ` Marshall Conover
2021-09-03 15:56 ` Warner Losh
2021-09-03 17:10   ` Adam Thornton
2021-09-03 17:28     ` Larry McVoy
2021-09-03 17:42       ` John Floren
2021-09-03 19:02       ` Lawrence Stewart
2021-09-03 19:11       ` Clem Cole
2021-09-03 17:46     ` [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware [ really a comment on SoCs ] Jon Steinhart
2021-09-16 18:38 ` [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) Dan Cross
2021-09-16 19:34   ` Jon Steinhart
2021-09-16 19:41     ` Larry McVoy
2021-09-16 23:14       ` Marshall Conover
2021-09-16 23:44         ` Rob Pike
2021-09-17  0:37           ` Larry McVoy
2021-09-17  1:38         ` Jon Steinhart
2021-09-17  3:54         ` John Cowan
2021-09-16 23:45       ` Jon Steinhart
2021-09-17  0:06         ` Al Kossow
2021-09-17  4:06           ` John Cowan
2021-09-17  4:18             ` Al Kossow
2021-09-17  0:32         ` Larry McVoy
2021-09-16 23:54       ` David Arnold
2021-09-17  1:10         ` Jon Steinhart
2021-09-17  1:28           ` Larry McVoy
2021-09-17  1:40             ` Jon Steinhart
2021-09-17  2:04               ` Larry McVoy
2021-09-17  2:21                 ` Jon Steinhart
2021-09-17  2:48           ` Theodore Ts'o
2021-09-17 17:39         ` Bakul Shah
2021-09-17 17:51           ` Jon Steinhart
2021-09-17 18:07             ` Larry McVoy
2021-09-17 21:03               ` Derek Fawcus
2021-09-17 22:11                 ` Larry McVoy
2021-09-19  4:05                   ` Theodore Ts'o [this message]
2021-09-17 18:34             ` Bakul Shah
2021-09-17 18:56               ` Jon Steinhart
2021-09-17 19:16                 ` Bakul Shah
2021-09-17 19:35                   ` Jon Steinhart
2021-09-17 15:56     ` Bakul Shah
2021-09-17 18:24       ` ron minnich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YUa3BUjRH7IAzcEL@mit.edu \
    --to=tytso@mit.edu \
    --cc=lm@mcvoy.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).