Message-ID: <84c4ee600c0dd235a0fcc257115807af7207b5f6.camel@wdc.com>
Date:   Thu, 5 Dec 2019 03:58:20 +0000
From:   Alistair Francis <Alistair.Francis@....com>
To:     "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>
CC:     "anup@...infault.org" <anup@...infault.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Atish Patra <Atish.Patra@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hch@....de" <hch@....de>
Subject: Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1

On Wed, 2019-12-04 at 18:54 -0800, Paul Walmsley wrote:
> On Wed, 4 Dec 2019, Alistair Francis wrote:
> 
> > That is just not what happens though.
> > 
> > It is too much to expect every distro to maintain a defconfig for
> > RISC- 
> > V. 
> 
> The major Linux distributions maintain their own kernel
> configuration 
> files, completely ignoring kernel defconfigs.  This has been so for a
> long 
> time.

That might be true for the traditional "desktop" distros, but embedded
distros (the main target for RISC-V at the moment) don't generally do
this.

> 
> > Which is why we currently use the defconfig as a base and apply
> > extra 
> > features that distro want on top.
> 
> As you know, since you've worked on some of the distribution builder 
> frameworks (not distributions) like OE and Buildroot, those build
> systems 
> have sophisticated kernel configuration patching and override systems
> that 
> can disable the debug options if the maintainers think it's a good
> idea to 
> do that.

Yes they do. As I said, we start with the defconfig and then apply
config changes on top. Every diversion is a maintainence burden so
where possible we don't make any changed. All of the QEMU machines
currently don't have config changes (and hopefully never will) as it's
a pain to maintain.

> 
> You've contributed to both Buildroot and OE meta-riscv RISC-V kernel 
> configuration fragments yourself, so this shouldn't be a problem for
> you 
> if you disagree with our choices here.  For example, here's an
> example of 
> how to patch defconfig directives out in Buildroot:
> 
>   
> https://git.buildroot.net/buildroot/tree/board/qemu/csky/linux-ck807.config.fragment#n3
> 
> I'm assuming you don't need an example for meta-riscv, since you've 
> already contributed RISC-V-related kernel configuration fragments to
> that 
> repository.

As I stated, this is possible. It's just a pain to maintain and for the
QEMU machines will probably not happen.

We are trying to remove RISC-V specific changes, not add more.

> 
> > Expecting every distro to have a kernel developers level of
> > knowledge
> > about configuring Kconfigs is just unrealistic.
> 
> I think it's false that only kernel developers know how to disable
> debug 
> options in Kconfig files.  As far as the underlying premise that one 
> shouldn't expect distribution maintainers to know how to change
> Kconfig 
> options, we'll just have to agree to disagree.

Do you really expect every disto to follow all of the kernel changes
and generate their own config based on what happened in the kernel tree
since the last release? We don't all just spend our days adjusting to
the Linux kernel.

This is espicially true for RISC-V as it's new and constantly changing.

> 
> > > distros and benchmarkers will create their own Kconfigs for their
> > > needs.
> > 
> > Like I said, that isn't true. After this patch is applied (and it
> > makes 
> > it to a release) all OE users will now have a slower RISC-V kernel.
> 
> OE doesn't have any RISC-V support upstream, so pure OE users won't
> notice 

That is just not true. You talk later about misinformation but this is
a blatent lie.

> any change at all.  Assuming you're talking about meta-riscv users:
> as 
> noted above, it's simple to automatically remove Kconfig entries you 
> disagree with, or add ones you want.
> 
> > Now image some company wants to investigate using a RISC-V chip for
> > their embedded project. They use OE/buildroot to build a quick test
> > setup and boot Linux. It now runs significantly slower then some
> > other
> > architecture and they don't choose RISC-V.
> 
> The best option for naive users who are seeking maximum performance
> is to 
> use a vendor BSP.  This goes beyond settings in a kernel config file:
> it 
> extends to compiler and linker optimization flags, LTO, accelerator 
> firmware and libraries, non-upstreamed performance-related patches, 
> vendor support, etc.

What? How many people actually do this for embedded systems.

I agree that if you really want to maximise it as much as you can you
will go to this effort, but I don't think most people do. I think we
all know that lots of times embedded Linux is just hacked until it
works and then shipped. In this case defaults are very important.

> 
> > Slowing down all users to help kernel developers debug seems like
> > the
> > wrong direction. Kernel developers should know enough to be able to
> > turn on the required configs, why does this need to be the default?
> 
> It's clear you strongly disagree with the decision to do this.  It's 
> certainly your right to do so.  But it's not good to spread
> misinformation 
> about how changing the defconfigs "slow[s] down all users," or 

What misinformation?

Anup shared benchmarking results indicating that this change has a 12%
performance decrease for everyone who uses the defconfig without
removing this change.

That is everyone who doesn't decide to remove config options from the
default config supplied by the people who wrote the code are now stuck
with a large performance hit. Passing the buck and saying that people
should be changing the defconfig cannot be the right solution here.

> exaggerating the difficulty for downstream software environments to
> back 
> this change out if they wish.

If you think it is that easy can you please submit the patches?

I understand it's easy to make decisions that simplfy your flow, but
this has real negative consequences in terms of performance for users
or complexity for maintainers. It would be nice if you take other users
/developers into account before merging changes.

Alistair

> 
> 
> - Paul

Powered by blists - more mailing lists