Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
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
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

  reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04  8:52 Paul Walmsley
2019-12-04 12:52 ` Anup Patel
2019-12-04 18:38   ` Alistair Francis
2019-12-04 19:38     ` Paul Walmsley
2019-12-04 19:50       ` Alistair Francis [this message]
2019-12-04 23:46         ` Anup Patel
2019-12-05  2:54         ` Paul Walmsley
2019-12-05  3:58           ` Alistair Francis
2019-12-05  5:35             ` David Abdurachmanov
2019-12-05 13:19               ` Anup Patel
2019-12-05 23:12             ` Paul Walmsley
2019-12-05 23:35               ` Alistair Francis
2019-12-05 23:46                 ` Alistair Francis
2019-12-06 21:12                   ` Carlos Eduardo de Paula
2019-12-06 21:15                     ` Anup Patel
2019-12-06 21:21                       ` Carlos Eduardo de Paula
2019-12-06 21:22                       ` Linus Torvalds
2019-12-04 19:25 ` pr-tracker-bot

Reply instructions:

You may reply publically 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: link

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git