From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Airlie <airlied@gmail.com>, Peter Jones <pjones@redhat.com>,
the arch/x86 maintainers <x86@kernel.org>,
Dave Airlie <airlied@redhat.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Lutomirski <luto@kernel.org>, Peter Anvin <hpa@zytor.com>
Subject: Re: [PATCH] efifb: allow user to disable write combined mapping.
Date: Thu, 20 Jul 2017 10:20:22 +0000 [thread overview]
Message-ID: <20170720102022.cwbqlf62nc3eal3f@gmail.com> (raw)
In-Reply-To: <CA+55aFyU3QrFeq4Lr9tgxR+6D9-eXZFZTzfqHdozHS72qE5q1w@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Jul 18, 2017 at 2:21 PM, Dave Airlie <airlied@gmail.com> wrote:
> >
> > Oh and just FYI, the machine I've tested this on has an mgag200 server
> > graphics card backing the framebuffer, but with just efifb loaded.
>
> Yeah, it looks like it needs special hardware - and particularly the
> kind of garbage hardware that people only have on servers.
>
> Why do server people continually do absolute sh*t hardware? It's crap,
> crap, crap across the board outside the CPU. Nasty and bad hacky stuff
> that nobody else would touch with a ten-foot pole, and the "serious
> enterprise" people lap it up like it was ambrosia.
>
> It's not just "graphics is bad anyway since we don't care". It's all
> the things they ostensibly _do_ care about too, like the disk and the
> fabric infrastructure. Buggy nasty crud.
I believe it's crappy for similar reasons why almost all other large scale pieces
of human technological infrastructure are crappy if you look deep under the hood:
transportation and communication networks, banking systems, manufacturing, you
name it.
The main reasons are:
- Cost of a clean redesign is an order of magnitude higher that the next delta
revision, once you have accumulated a few decades of legacy.
- The path dependent evolutionary legacies become so ugly after time that most
good people will run away from key elements - so there's not enough internal
energy to redesign and implement a clean methodology from grounds up.
- Even if there are enough good people, the benefits of a clean design are a long
term benefit, constantly hindered by short term pricing.
- For non-experts it's hard to tell a good, clean redesign from a flashy but
fundamentally flawed redesign. Both are expensive and the latter can have
disastrous outcomes.
- These are high margin businesses, with customers captured by legacies, where
you can pass down the costs to customers, which hides the true costs of crap.
i.e. typical free market failure due high complexity combined with (very) long
price propagation latencies and opaqueness of pricing.
I believe the only place where you'll find overall beautiful server hardware as a
rule and not as an exception is in satellite technology: when the unit price is in
excess of $100m, expected life span is 10-20 years with no on-site maintenance,
and it's all running in a fundamentally hostile environment, then clean and robust
hardware design is forced at every step by physics.
Humanity is certainly able to design beautiful hardware, once all other options
are exhausted.
Thanks,
Ingo
next prev parent reply other threads:[~2017-07-20 10:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 6:09 [PATCH] efifb: allow user to disable write combined mapping Dave Airlie
2017-07-18 14:34 ` Peter Jones
2017-07-18 19:57 ` Linus Torvalds
2017-07-18 20:44 ` Dave Airlie
2017-07-18 21:21 ` Dave Airlie
2017-07-18 22:22 ` Linus Torvalds
2017-07-18 23:16 ` Dave Airlie
2017-07-18 23:16 ` Dave Airlie
2017-07-19 0:00 ` Dave Airlie
2017-07-19 1:15 ` Linus Torvalds
2017-07-20 4:07 ` Dave Airlie
2017-07-20 4:28 ` Andy Lutomirski
2017-07-20 4:44 ` Linus Torvalds
2017-07-21 4:27 ` Dave Airlie
2017-07-20 10:20 ` Ingo Molnar [this message]
2017-07-31 19:13 ` H. Peter Anvin
2017-07-25 4:00 ` Dave Airlie
2017-07-25 8:56 ` Bartlomiej Zolnierkiewicz
[not found] ` <CGME20170731171022epcas1p2c5537a0a79eca05a729773d4cabaac27@epcas1p2.samsung.com>
2017-07-31 17:10 ` Bartlomiej Zolnierkiewicz
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=20170720102022.cwbqlf62nc3eal3f@gmail.com \
--to=mingo@kernel.org \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=b.zolnierkie@samsung.com \
--cc=hpa@zytor.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pjones@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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).