[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190425143902.GA30715@infradead.org>
Date: Thu, 25 Apr 2019 07:39:02 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Aaron Ma <aaron.ma@...onical.com>
Cc: Keith Busch <kbusch@...nel.org>, keith.busch@...el.com,
axboe@...com, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org,
Maxim Levitsky <mlevitsk@...hat.com>
Subject: Re: [PATCH] nvme: determine the number of IO queues
On Thu, Apr 18, 2019 at 10:21:03PM +0800, Aaron Ma wrote:
>
>
> On 4/18/19 9:48 PM, Keith Busch wrote:
> > It does change the default behavior. If I have a degraded controller that
> > can't do IO in a machine with 1000's of CPUs, I have to iterate this
> > non-standard behavior 1000's of times before the drive is servicable
> > again. We currenlty figure that out in just a single try.
> >
> > At least the quirks document *why* the driver is doing non-standard
> > behavior. We do the IO queue quirks for Macbooks, for example.
> >
> > But why don't you file a bug report with the device vendor instead? Surely
> > a firmware fix provides the best possible outcome, and would make this
> > device work not only in all versions of Linux, but also every standard
> > compliant driver for any OS.
>
> I will do it, no v2 for now.
Honestly, unless this is a device shiping in a max market consumer
product already I don't think we should work around this crap at all,
given that this device has obviously never been tested at all. It
really needs a firmware fix instead of a host workaround.
Powered by blists - more mailing lists