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

[Anup Patel]

On Thu, Dec 5, 2019 at 11:06 AM David Abdurachmanov
<david.abdurachmanov@xxxxxxxxx> wrote:
>
> On Thu, Dec 5, 2019 at 5:58 AM Alistair Francis
> <Alistair.Francis@xxxxxxx> 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.

Thanks for the confirmation. Unfortunately, this does not apply to
Yocto and Buildroot (and there could be others too).

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

Yes, we cannot generalize that all distros use their own configs. Lot of
embedded users prefer Yocto and Buildroot which certainly depend on
Linux defconfigs.

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

That's what I had suggested in my first comment on Paul's patch but
he did not respond. Unfortunately, we are having this conversation here
after the patch was merged by Paul without any discussions.
(Refer, https://lkml.org/lkml/2019/11/22/2084)

I have also sent a follow-up patch to add debug defconfigs.
(Refer, https://lkml.org/lkml/2019/12/4/1411)

There are two major concerns here:

1. Linux development process not being followed
Like I mentioned, I had already commented on Paul's patch. He simply
ignored my concerns about performance impact. This is a bad trend being
established in Linux RISC-V development.

2. Generalizing that all distros use their own config
This generalization is not true for any architecture. In fact, there are
lot of users (and distros) across architectures who depend on Linux
defconfig for building kernel image.

> Fedora). Why not use config fragment here (e.g. call it debug.config like
> in powerpc)?

This would be an interesting thing to explore if it benefits everyone but
for now we need separate debug defconfigs.

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

Regards,
Anup