From: Keith Busch <kbusch@kernel.org>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@fb.com>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org
Subject: Re: `nvme_disable_ctrl()` takes 411 ms on a Dell XPS 13 with SK hynix PC300 NVMEe
Date: Wed, 1 May 2024 23:03:14 +0100 [thread overview]
Message-ID: <ZjK8IjHfwpAMQajT@kbusch-mbp> (raw)
In-Reply-To: <93c29602-b162-47b3-9a03-a18158b9f6ef@molgen.mpg.de>
On Wed, May 01, 2024 at 10:58:05PM +0200, Paul Menzel wrote:
> Am 01.05.24 um 09:58 schrieb Keith Busch:
> > Exactly. Unless the device reports a lower D3 entry latency, then this
> > sounds like everything is working-as-designed.
>
> Maybe according to the spec, but I have a hard time to believe, that disks
> should take longer to shut down than coreboot to initialize a mainboard.
That doesn't seem too hard to believe to me. A safe shutdown can often
take a while time for an SSD. I've seen other implementations orders of
magnitude worse than what you're showing. You could do an unsafe
shutdown instead, but the device will just take even more time to enable
on its next power-on.
> In the end, in my opinion, users cannot make an informed decision, if these
> things are hidden. If it would be visible somehow in the logs - maybe not
> warning but info level - then even not so technical users could inform
> themselves and factor this in their buying decision.
What good is it to advertise a shutdown time when vendors are clearly
unreliable at reporting an accurate value? If you need to see the driver
report it from emperical testing, then you've already bought the device,
right?
> > You can check your device's advertised shutdown time (assuming your
> > device is nvme0):
> >
> > nvme id-ctrl /dev/nvme0 | grep rtd3e
> >
> > The value is reported in microseconds. If it shows 0, then the device
> > doesn't report an expected shutdown time.
>
> Thank you for sharing. It´s 60 ms:
next prev parent reply other threads:[~2024-05-01 22:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 4:29 `nvme_disable_ctrl()` takes 411 ms on a Dell XPS 13 with SK hynix PC300 NVMEe Paul Menzel
2024-05-01 4:51 ` Christoph Hellwig
2024-05-01 7:58 ` Keith Busch
2024-05-01 20:58 ` Paul Menzel
2024-05-01 22:03 ` Keith Busch [this message]
2024-05-02 6:04 ` Paul Menzel
2024-05-02 6:12 ` Paul Menzel
2024-05-02 8:43 ` Keith Busch
2024-05-02 15:57 ` Jeremy Allison
2024-05-03 5:52 ` Paul Menzel
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=ZjK8IjHfwpAMQajT@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=linux-nvme@lists.infradead.org \
--cc=pmenzel@molgen.mpg.de \
--cc=sagi@grimberg.me \
/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
Be 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.