From: Alistair Francis <Alistair.Francis@wdc.com> To: "paul.walmsley@sifive.com" <paul.walmsley@sifive.com> Cc: "anup@brainfault.org" <anup@brainfault.org>, "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>, "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>, Atish Patra <Atish.Patra@wdc.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "hch@lst.de" <hch@lst.de> Subject: Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1 Date: Wed, 4 Dec 2019 19:50:53 +0000 [thread overview] Message-ID: <81530734312456aab8b9625d7e9bb071c43db1c5.camel@wdc.com> (raw) In-Reply-To: <alpine.DEB.2.21.9999.1912041128400.186402@viisi.sifive.com> On Wed, 2019-12-04 at 11:38 -0800, Paul Walmsley wrote: > Alistair, Anup, > > On Wed, 4 Dec 2019, Alistair Francis wrote: > > > On Wed, 2019-12-04 at 18:22 +0530, Anup Patel wrote: > > > > > I had commented on your patch but my comments are still > > > not addressed. > > > > > > Various debug options enabled by this patch have performance > > > impact. Instead of enabling these debug options in primary > > > defconfigs, I suggest to have separate debug defconfigs with > > > these options enabled. > > > > +1 > > > > OE uses the defconfig (as I'm sure other distros do) and slowing > > down > > users seems like a bad idea. > > While I respect your points of view, our defconfigs are oriented > towards > kernel developers. This is particularly important when right now the > only That is just not what happens though. It is too much to expect every distro to maintain a defconfig for RISC- V. There are constantly new features that need to be enabled/disabled in the configs and it isn't always clear to outsiders. Which is why we currently use the defconfig as a base and apply extra features that distro want on top. Expecting every distro to have a kernel developers level of knowledge about configuring Kconfigs is just unrealistic. > RISC-V hardware on the market are test chips. Our expectation is > that Treating RISC-V as a test architecture seems like a good way to make sure that is all it ever is. > 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. This also applies to buildroot and probably other distos. 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. 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? Alistair > > Going forward, we'll probably add a few more validation and debug > options, > as Palmer suggested during the patch discussion. > > > - Paul
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Francis <Alistair.Francis@wdc.com> To: "paul.walmsley@sifive.com" <paul.walmsley@sifive.com> Cc: "anup@brainfault.org" <anup@brainfault.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Atish Patra <Atish.Patra@wdc.com>, "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>, "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>, "hch@lst.de" <hch@lst.de> Subject: Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1 Date: Wed, 4 Dec 2019 19:50:53 +0000 [thread overview] Message-ID: <81530734312456aab8b9625d7e9bb071c43db1c5.camel@wdc.com> (raw) In-Reply-To: <alpine.DEB.2.21.9999.1912041128400.186402@viisi.sifive.com> On Wed, 2019-12-04 at 11:38 -0800, Paul Walmsley wrote: > Alistair, Anup, > > On Wed, 4 Dec 2019, Alistair Francis wrote: > > > On Wed, 2019-12-04 at 18:22 +0530, Anup Patel wrote: > > > > > I had commented on your patch but my comments are still > > > not addressed. > > > > > > Various debug options enabled by this patch have performance > > > impact. Instead of enabling these debug options in primary > > > defconfigs, I suggest to have separate debug defconfigs with > > > these options enabled. > > > > +1 > > > > OE uses the defconfig (as I'm sure other distros do) and slowing > > down > > users seems like a bad idea. > > While I respect your points of view, our defconfigs are oriented > towards > kernel developers. This is particularly important when right now the > only That is just not what happens though. It is too much to expect every distro to maintain a defconfig for RISC- V. There are constantly new features that need to be enabled/disabled in the configs and it isn't always clear to outsiders. Which is why we currently use the defconfig as a base and apply extra features that distro want on top. Expecting every distro to have a kernel developers level of knowledge about configuring Kconfigs is just unrealistic. > RISC-V hardware on the market are test chips. Our expectation is > that Treating RISC-V as a test architecture seems like a good way to make sure that is all it ever is. > 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. This also applies to buildroot and probably other distos. 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. 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? Alistair > > Going forward, we'll probably add a few more validation and debug > options, > as Palmer suggested during the patch discussion. > > > - Paul
next prev parent reply other threads:[~2019-12-04 19:50 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-04 8:52 [GIT PULL] Second set of RISC-V updates for v5.5-rc1 Paul Walmsley 2019-12-04 12:52 ` Anup Patel 2019-12-04 12:52 ` Anup Patel 2019-12-04 18:38 ` Alistair Francis 2019-12-04 18:38 ` Alistair Francis 2019-12-04 19:38 ` Paul Walmsley 2019-12-04 19:38 ` Paul Walmsley 2019-12-04 19:50 ` Alistair Francis [this message] 2019-12-04 19:50 ` Alistair Francis 2019-12-04 23:46 ` Anup Patel 2019-12-04 23:46 ` Anup Patel 2019-12-05 2:54 ` Paul Walmsley 2019-12-05 2:54 ` Paul Walmsley 2019-12-05 3:58 ` Alistair Francis 2019-12-05 3:58 ` Alistair Francis 2019-12-05 5:35 ` David Abdurachmanov 2019-12-05 5:35 ` David Abdurachmanov 2019-12-05 13:19 ` Anup Patel 2019-12-05 13:19 ` Anup Patel 2019-12-05 23:12 ` Paul Walmsley 2019-12-05 23:12 ` Paul Walmsley 2019-12-05 23:35 ` Alistair Francis 2019-12-05 23:35 ` Alistair Francis 2019-12-05 23:46 ` Alistair Francis 2019-12-05 23:46 ` Alistair Francis 2019-12-06 21:12 ` Carlos Eduardo de Paula 2019-12-06 21:12 ` Carlos Eduardo de Paula 2019-12-06 21:15 ` Anup Patel 2019-12-06 21:15 ` Anup Patel 2019-12-06 21:21 ` Carlos Eduardo de Paula 2019-12-06 21:21 ` Carlos Eduardo de Paula 2019-12-06 21:22 ` Linus Torvalds 2019-12-06 21:22 ` Linus Torvalds 2019-12-04 19:25 ` pr-tracker-bot 2019-12-04 19:25 ` pr-tracker-bot
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=81530734312456aab8b9625d7e9bb071c43db1c5.camel@wdc.com \ --to=alistair.francis@wdc.com \ --cc=Atish.Patra@wdc.com \ --cc=anup@brainfault.org \ --cc=hch@lst.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=paul.walmsley@sifive.com \ --cc=torvalds@linux-foundation.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.