On Tue, Sep 18, 2018 at 01:59:01PM -0700, Bart Van Assche wrote:
> Instead of scheduling runtime resume of a request queue after a
> request has been queued, schedule asynchronous resume during request
> allocation. The new pm_request_resume() calls occur after
> blk_queue_enter() has increased
Hi Bart
On 09/19/2018 01:44 AM, Bart Van Assche wrote:
>>> + * ago. Since blk_queue_enter() is called by the request allocation
>>> + * code before pm_request_resume(), if no requests have a tag assigned
>>> + * it is safe to suspend the device.
>>> + */
>>> + ret = -EBUSY;
>>>
On Tue, Sep 18, 2018 at 05:02:47PM -0700, Bart Van Assche wrote:
> On 9/18/18 4:24 PM, Omar Sandoval wrote:
> > On Tue, Sep 18, 2018 at 02:20:59PM -0700, Bart Van Assche wrote:
> > > Can you have a look at the updated master branch of
> > > https://github.com/bvanassche/blktests? That code should
On 9/18/18 4:24 PM, Omar Sandoval wrote:
On Tue, Sep 18, 2018 at 02:20:59PM -0700, Bart Van Assche wrote:
Can you have a look at the updated master branch of
https://github.com/bvanassche/blktests? That code should no longer fail if
unloading the nvme kernel module fails. Please note that you
On Tue, Sep 18, 2018 at 02:20:59PM -0700, Bart Van Assche wrote:
> On 8/23/18 5:21 PM, Omar Sandoval wrote:
> > On Thu, Aug 23, 2018 at 01:53:33AM +, Bart Van Assche wrote:
> > > On Tue, 2018-08-21 at 08:46 +0200, Johannes Thumshirn wrote:
> > > > On Mon, Aug 20, 2018 at 03:46:45PM +, Bart
On 8/23/18 5:21 PM, Omar Sandoval wrote:
On Thu, Aug 23, 2018 at 01:53:33AM +, Bart Van Assche wrote:
On Tue, 2018-08-21 at 08:46 +0200, Johannes Thumshirn wrote:
On Mon, Aug 20, 2018 at 03:46:45PM +, Bart Van Assche wrote:
Moving these tests into the nvme directory is possible but
Instead of allowing requests that are not power management requests
to enter the queue in runtime suspended status (RPM_SUSPENDED), make
the blk_get_request() caller block. This change fixes a starvation
issue: it is now guaranteed that power management requests will be
executed no matter how many
Now that the blk-mq core processes power management requests
(marked with RQF_PREEMPT) in other states than RPM_ACTIVE, enable
runtime power management for blk-mq.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Jianchao Wang
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Instead of scheduling runtime resume of a request queue after a
request has been queued, schedule asynchronous resume during request
allocation. The new pm_request_resume() calls occur after
blk_queue_enter() has increased the q_usage_counter request queue
member. This change is needed for a later
Move the code for runtime power management from blk-core.c into the
new source file blk-pm.c. Move the corresponding declarations from
into . For CONFIG_PM=n, leave out
the declarations of the functions that are not used in that mode.
This patch not only reduces the number of #ifdefs in the block
Make it easier to understand the purpose of the functions that iterate
over requests by documenting their purpose. Fix two minor spelling
mistakes in comments in these functions.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Jianchao Wang
Cc: Hannes Reinecke
Cc:
Move the pm_request_resume() and pm_runtime_mark_last_busy() calls into
two new functions and thereby separate legacy block layer code from code
that works for both the legacy block layer and blk-mq. A later patch will
add calls to the new functions in the blk-mq code.
Signed-off-by: Bart Van
The RQF_PREEMPT flag is used for three purposes:
- In the SCSI core, for making sure that power management requests
are executed even if a device is in the "quiesced" state.
- For domain validation by SCSI drivers that use the parallel port.
- In the IDE driver, for IDE preempt requests.
Rename
This function will be used in the patch "Make blk_get_request() block for
non-PM requests while suspended".
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Jianchao Wang
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Alan Stern
---
block/blk-mq-tag.c | 44
Hello Jens,
One of the pieces that is missing before blk-mq can be made the default is
implementing runtime power management support for blk-mq. This patch series
not only implements runtime power management for blk-mq but also fixes a
starvation issue in the power management code for the legacy
On 9/17/18 7:39 PM, jianchao.wang wrote:
On 09/18/2018 04:15 AM, Bart Van Assche wrote:
Instead of allowing requests that are not power management requests
to enter the queue in runtime suspended status (RPM_SUSPENDED), make
the blk_get_request() caller block. This change fixes a starvation
Hi Hans,
thanks a lot for your comments! I will send you a git repo to test. I
have a patch which enables/disables RAIL via ioctl and will send that
as well.
Heiner
On Tue, Sep 18, 2018 at 4:46 AM Hans Holmberg
wrote:
>
> On Mon, Sep 17, 2018 at 7:29 AM Heiner Litz wrote:
> >
> > Hi All,
> >
On Tue, Sep 18, 2018 at 4:28 AM Hans Holmberg
wrote:
>
> On Mon, Sep 17, 2018 at 7:30 AM Heiner Litz wrote:
> >
> > In prepartion of supporting RAIL, add the RAIL API.
> >
> > Signed-off-by: Heiner Litz
> > ---
> > drivers/lightnvm/pblk-rail.c | 808 +++
> >
On Mon, Sep 17, 2018 at 7:29 AM Heiner Litz wrote:
>
> Hi All,
> this patchset introduces RAIL, a mechanism to enforce low tail read latency
> for
> lightnvm OCSSD devices. RAIL leverages redundancy to guarantee that reads are
> always served from LUNs that do not serve a high latency operation
On Mon, Sep 17, 2018 at 7:30 AM Heiner Litz wrote:
>
> Integrate Redundant Array of Independent Luns (RAIL) into lightnvm. RAIL
> enforces low tail read latency by guaranteeing that reads are never
> serialized behind writes and erases to the same LUN. Whenever LUNs serve a
> high latency
On Mon, Sep 17, 2018 at 7:30 AM Heiner Litz wrote:
>
> In prepartion of supporting RAIL, add the RAIL API.
>
> Signed-off-by: Heiner Litz
> ---
> drivers/lightnvm/pblk-rail.c | 808 +++
> drivers/lightnvm/pblk.h | 63 ++-
> 2 files changed, 870
Hi Ming
On 09/18/2018 03:42 PM, Ming Lei wrote:
> On Tue, Sep 18, 2018 at 09:17:12AM +0800, jianchao.wang wrote:
>> Hi Ming
>>
>> On 09/17/2018 08:07 PM, Ming Lei wrote:
> This way will delay runtime pm or system suspend until the queue is
> unfrozen,
> but it isn't reasonable.
On Tue, Sep 18, 2018 at 09:17:12AM +0800, jianchao.wang wrote:
> Hi Ming
>
> On 09/17/2018 08:07 PM, Ming Lei wrote:
> >>> This way will delay runtime pm or system suspend until the queue is
> >>> unfrozen,
> >>> but it isn't reasonable.
> >> This interface is for the __scsi_execute only, before
23 matches
Mail list logo
