On Mon, Jul 05, 2021 at 10:40:21AM +0000, Shivamurthy Shastri (sshivamurthy) wrote:
> Micron Confidential
>
> Hi Christoph,
>
> >
> >
> > On Mon, Jul 05, 2021 at 10:11:57AM +0000, [email protected] wrote:
> > > From: Shivamurthy Shastri <[email protected]>
> > >
> > > Enabling the abrupt shutdown support. In this shutdown type host does
> > > not need to send Delete I/O Submission Queue and Delete I/O Completion
> > > queue commands to the device.
> >
> > Why?
>
> This is to achieve faster shutdown at the cost of data in-flight.
What is the actual use case, and why would a module paramter be a good
interface?
Micron Confidential
> >
> > Hi Christoph,
> >
> > >
> > >
> > > On Mon, Jul 05, 2021 at 10:11:57AM +0000, [email protected]
> wrote:
> > > > From: Shivamurthy Shastri <[email protected]>
> > > >
> > > > Enabling the abrupt shutdown support. In this shutdown type host does
> > > > not need to send Delete I/O Submission Queue and Delete I/O Completion
> > > > queue commands to the device.
> > >
> > > Why?
> >
> > This is to achieve faster shutdown at the cost of data in-flight.
>
> What is the actual use case, and why would a module paramter be a good
> interface?
For systems with passive electronic components to handle power-loss/battery-removal,
CC.SHN=10b will help to achieve safer shutdown with relatively lower power back-up
requirements (at lower cost).
The module parameter gives flexibility to the host to decide shutdown type even during
boot failure.
Thanks,
Shiva
Micron Confidential
On Mon, Jul 05, 2021 at 11:15:51AM +0000, Shivamurthy Shastri (sshivamurthy) wrote:
> For systems with passive electronic components to handle power-loss/battery-removal,
> CC.SHN=10b will help to achieve safer shutdown with relatively lower power back-up
> requirements (at lower cost).
>
> The module parameter gives flexibility to the host to decide shutdown type even during
> boot failure.
If you have a device that always prefers an abrupt please introduce a TP
in the NVMe technical working group so that the hosts automatically
do the right thing. Requiring sysadmin intervention using a global
kernel parameter is not the way to do this.
On Mon, Jul 05, 2021 at 01:53:49PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 05, 2021 at 11:15:51AM +0000, Shivamurthy Shastri (sshivamurthy) wrote:
> > For systems with passive electronic components to handle power-loss/battery-removal,
> > CC.SHN=10b will help to achieve safer shutdown with relatively lower power back-up
> > requirements (at lower cost).
> >
> > The module parameter gives flexibility to the host to decide shutdown type even during
> > boot failure.
>
> If you have a device that always prefers an abrupt please introduce a TP
> in the NVMe technical working group so that the hosts automatically
> do the right thing. Requiring sysadmin intervention using a global
> kernel parameter is not the way to do this.
Is it the device that wants an abrupt shutdown or the platform? If the
platform's power is running on limited back-up supply, and could inform
the kernel's power management subsystem of this, then a driver could use
that to determine if the quick shutdown is appropriate.
Micron Confidential
Hi,
>
>
> On Mon, Jul 05, 2021 at 01:53:49PM +0200, Christoph Hellwig wrote:
> > On Mon, Jul 05, 2021 at 11:15:51AM +0000, Shivamurthy Shastri
> (sshivamurthy) wrote:
> > > For systems with passive electronic components to handle power-
> loss/battery-removal,
> > > CC.SHN=10b will help to achieve safer shutdown with relatively lower power
> back-up
> > > requirements (at lower cost).
> > >
> > > The module parameter gives flexibility to the host to decide shutdown type
> even during
> > > boot failure.
> >
> > If you have a device that always prefers an abrupt please introduce a TP
> > in the NVMe technical working group so that the hosts automatically
> > do the right thing. Requiring sysadmin intervention using a global
> > kernel parameter is not the way to do this.
The abrupt shutdown notification is already part of NVMe Specification.
>
> Is it the device that wants an abrupt shutdown or the platform? If the
> platform's power is running on limited back-up supply, and could inform
> the kernel's power management subsystem of this, then a driver could use
> that to determine if the quick shutdown is appropriate.
Yes, the platform is running on limited back-up supply. In this case, abrupt shutdown
option will help to achieve shutdown with relatively low back-up requirements.
Please let me know if you want to include the abrupt shutdown as part of
static const struct dev_pm_ops nvme_dev_pm_ops = {
.suspend = nvme_suspend,
.....
Thanks,
Shiva
Micron Confidential
On Tue, Jul 06, 2021 at 08:14:45AM +0000, Shivamurthy Shastri (sshivamurthy) wrote:
> > Is it the device that wants an abrupt shutdown or the platform? If the
> > platform's power is running on limited back-up supply, and could inform
> > the kernel's power management subsystem of this, then a driver could use
> > that to determine if the quick shutdown is appropriate.
>
> Yes, the platform is running on limited back-up supply. In this case, abrupt shutdown
> option will help to achieve shutdown with relatively low back-up requirements.
>
> Please let me know if you want to include the abrupt shutdown as part of
>
> static const struct dev_pm_ops nvme_dev_pm_ops = {
> .suspend = nvme_suspend,
> .....
Are you suggesting creating a new pm callback just for this? I don't
think that's necessary.
I was considering just adding a bit to the pm_suspend_global_flags,
something like the patch below. You just have to fill in the platform
specific parts to set the flag.
---
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 8af13ba60c7e..f43c0b2313d0 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -210,9 +210,10 @@ extern int suspend_valid_only_mem(suspend_state_t state);
extern unsigned int pm_suspend_global_flags;
-#define PM_SUSPEND_FLAG_FW_SUSPEND BIT(0)
-#define PM_SUSPEND_FLAG_FW_RESUME BIT(1)
-#define PM_SUSPEND_FLAG_NO_PLATFORM BIT(2)
+#define PM_SUSPEND_FLAG_FW_SUSPEND BIT(0)
+#define PM_SUSPEND_FLAG_FW_RESUME BIT(1)
+#define PM_SUSPEND_FLAG_NO_PLATFORM BIT(2)
+#define PM_SUSPEND_FLAG_POWER_LOSS_IMMINENT BIT(3)
static inline void pm_suspend_clear_flags(void)
{
@@ -234,6 +235,11 @@ static inline void pm_set_suspend_no_platform(void)
pm_suspend_global_flags |= PM_SUSPEND_FLAG_NO_PLATFORM;
}
+static inline void pm_set_power_loss_imminent(void)
+{
+ pm_suspend_global_flags |= PM_SUSPEND_FLAG_POWER_LOSS_IMMINENT;
+}
+
/**
* pm_suspend_via_firmware - Check if platform firmware will suspend the system.
*
@@ -291,6 +297,21 @@ static inline bool pm_suspend_no_platform(void)
return !!(pm_suspend_global_flags & PM_SUSPEND_FLAG_NO_PLATFORM);
}
+/**
+ * pm_power_loss_imminent - Check if platform is running on limited backup
+ * power source
+ *
+ * To be called during system-wide power management transitions to sleep states.
+ *
+ * Return 'true' if power loss may be imminent due to platform running on
+ * limited backup supply. If set during a shutdown, drivers should use any
+ * available shortcuts to prepare their device for abrupt power loss.
+ */
+static inline bool pm_power_loss_imminent(void)
+{
+ return !!(pm_suspend_global_flags & PM_SUSPEND_FLAG_POWER_LOSS_IMMINENT);
+}
+
/* Suspend-to-idle state machnine. */
enum s2idle_states {
S2IDLE_STATE_NONE, /* Not suspended/suspending. */
--