Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1

[David Abdurachmanov <david.abdurachmanov@gmail.com>]

On Thu, Dec 5, 2019 at 5:58 AM Alistair Francis
<Alistair.Francis@wdc.com> wrote:
>
> 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.

I can confirm that Fedora/CentOS/RHEL do not depend on default
config in kernel. Same seems to apply to Ubuntu, Arch and probably
others. We maintain our own configs.

>
> >
> > > 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.

I cannot talk for all distros (there are too many), but major desktop
distributions do that. For the 1st few RCs of a new kernel version I
will be adjusting Fedora/RISCV configuration based on whatever
changes land.

Of course looking at default defconfig is part of that process.

>
> 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.

I would prefer to have a separate config for debug (that's what we do in
Fedora). Why not use config fragment here (e.g. call it debug.config like
in powerpc)?

See:
https://github.com/torvalds/linux/commit/c1bc6f93f95970f917caaac544a374862e84df52
https://elinux.org/images/3/39/Managing-Linux-Kernel-Configurations-with-Config-Fragments-Darren-Hart-VMware.pdf

david

>
> Alistair
>
> >
> >
> > - Paul