All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Greg KH <gregkh@linuxfoundation.org>,
	Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: blk-mq breaks suspend even with runtime PM patch
Date: Tue, 08 Aug 2017 18:34:01 +0200	[thread overview]
Message-ID: <1502210041.7877.5.camel@gmx.de> (raw)
In-Reply-To: <20170808162252.GC23338@kroah.com>

On Tue, 2017-08-08 at 09:22 -0700, Greg KH wrote:
> On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote:
> > Hello Mike et al.
> >=20
> > On ned=C4=9Ble 30. =C4=8Dervence 2017 7:12:31 CEST Mike Galbraith wrote=
:
> > > FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if
> > > stable fixed it.
> >=20
> > My build already includes v4.12.4.
> >=20
> > > If not, I'd find these two commits irresistible.
> > >=20
> > > 5f042e7cbd9eb blk-mq: Include all present CPUs in the default queue m=
apping
> > > 4b855ad37194f blk-mq: Create hctx for each present CPU
> >=20
> > I've applied these 2 commits, and cannot reproduce the issue anymore. L=
ooks=20
> > like a perfect hit, thanks!
> >=20
> > > 'course applying random upstream bits does come with some risk, tryin=
g
> > > a kernel already containing them has less "entertainment" potential.=
=20
> >=20
> > Should you consider applying them to v4.12.x stable series? CC'ing Greg=
 just=20
> > in case.
>=20
> I can queue these up if I get an ack from the developers/maintainers
> that it is ok to do so...
>=20
> {hint}

{hint++}

Those commits take Steven Rostedt's hotplug stress script runtime down
from 4 _minutes_ down to 7 seconds for my RT tree, so I'm rather hoping
you hear an "ACK" too.

	-Mike

WARNING: multiple messages have this Message-ID (diff)
From: Mike Galbraith <efault@gmx.de>
To: Greg KH <gregkh@linuxfoundation.org>,
	Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: blk-mq breaks suspend even with runtime PM patch
Date: Tue, 08 Aug 2017 18:34:01 +0200	[thread overview]
Message-ID: <1502210041.7877.5.camel@gmx.de> (raw)
In-Reply-To: <20170808162252.GC23338@kroah.com>

On Tue, 2017-08-08 at 09:22 -0700, Greg KH wrote:
> On Sun, Jul 30, 2017 at 03:50:15PM +0200, Oleksandr Natalenko wrote:
> > Hello Mike et al.
> > 
> > On neděle 30. července 2017 7:12:31 CEST Mike Galbraith wrote:
> > > FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if
> > > stable fixed it.
> > 
> > My build already includes v4.12.4.
> > 
> > > If not, I'd find these two commits irresistible.
> > > 
> > > 5f042e7cbd9eb blk-mq: Include all present CPUs in the default queue mapping
> > > 4b855ad37194f blk-mq: Create hctx for each present CPU
> > 
> > I've applied these 2 commits, and cannot reproduce the issue anymore. Looks 
> > like a perfect hit, thanks!
> > 
> > > 'course applying random upstream bits does come with some risk, trying
> > > a kernel already containing them has less "entertainment" potential. 
> > 
> > Should you consider applying them to v4.12.x stable series? CC'ing Greg just 
> > in case.
> 
> I can queue these up if I get an ack from the developers/maintainers
> that it is ok to do so...
> 
> {hint}

{hint++}

Those commits take Steven Rostedt's hotplug stress script runtime down
from 4 _minutes_ down to 7 seconds for my RT tree, so I'm rather hoping
you hear an "ACK" too.

	-Mike

  parent reply	other threads:[~2017-08-08 16:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-29 15:27 blk-mq breaks suspend even with runtime PM patch Oleksandr Natalenko
2017-07-29 21:17 ` Oleksandr Natalenko
2017-07-29 21:17   ` Oleksandr Natalenko
2017-07-30  5:12 ` Mike Galbraith
2017-07-30  5:12   ` Mike Galbraith
2017-07-30 13:50   ` Oleksandr Natalenko
2017-07-30 13:50     ` Oleksandr Natalenko
2017-08-08 16:22     ` Greg KH
2017-08-08 16:33       ` Jens Axboe
2017-08-08 16:36         ` Oleksandr Natalenko
2017-08-08 16:36           ` Oleksandr Natalenko
2017-08-08 16:43           ` Greg KH
2017-08-08 16:46             ` Oleksandr Natalenko
2017-08-08 16:46               ` Oleksandr Natalenko
2017-08-08 16:34       ` Mike Galbraith [this message]
2017-08-08 16:34         ` Mike Galbraith
2017-08-08 16:44         ` Greg KH
2017-08-08 16:50           ` Mike Galbraith
2017-08-08 16:50             ` Mike Galbraith
2017-08-08 18:33             ` Mike Galbraith
2017-08-08 18:33               ` Mike Galbraith
2017-08-08 18:35               ` Jens Axboe

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=1502210041.7877.5.camel@gmx.de \
    --to=efault@gmx.de \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr@natalenko.name \
    /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.