Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1706742 > unrolled thread

Re: blk-mq breaks suspend even with runtime PM patch

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: blk-mq breaks suspend even with runtime PM patch Greg KH <gregkh@linuxfoundation.org> - 2017-08-08 18:30 +0200
    Re: blk-mq breaks suspend even with runtime PM patch Mike Galbraith <efault@gmx.de> - 2017-08-08 18:40 +0200
      Re: blk-mq breaks suspend even with runtime PM patch Greg KH <gregkh@linuxfoundation.org> - 2017-08-08 18:50 +0200
        Re: blk-mq breaks suspend even with runtime PM patch Mike Galbraith <efault@gmx.de> - 2017-08-08 19:00 +0200
          Re: blk-mq breaks suspend even with runtime PM patch Mike Galbraith <efault@gmx.de> - 2017-08-08 20:40 +0200
            Re: blk-mq breaks suspend even with runtime PM patch Jens Axboe <axboe@kernel.dk> - 2017-08-08 20:40 +0200
    Re: blk-mq breaks suspend even with runtime PM patch Jens Axboe <axboe@kernel.dk> - 2017-08-08 18:40 +0200
      Re: blk-mq breaks suspend even with runtime PM patch Oleksandr Natalenko <oleksandr@natalenko.name> - 2017-08-08 18:40 +0200
        Re: blk-mq breaks suspend even with runtime PM patch Greg KH <gregkh@linuxfoundation.org> - 2017-08-08 18:50 +0200
          Re: blk-mq breaks suspend even with runtime PM patch Oleksandr Natalenko <oleksandr@natalenko.name> - 2017-08-08 18:50 +0200

#1706742 — Re: blk-mq breaks suspend even with runtime PM patch

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}

thanks,

greg k-h

[toc] | [next] | [standalone]

#1706746

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

[toc] | [prev] | [next] | [standalone]

#1706754

On Tue, Aug 08, 2017 at 06:34:01PM +0200, Mike Galbraith wrote:
> 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.

Oh, nice!

Should these go back farther than 4.12?  Looks like they apply cleanly
to 4.9, didn't look older than that...

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1706765

On Tue, 2017-08-08 at 09:44 -0700, Greg KH wrote:
> 
> Should these go back farther than 4.12?  Looks like they apply cleanly
> to 4.9, didn't look older than that...

I met prerequisites at 4.11, but I wasn't patching anything remotely
resembling virgin source.

	-Mike

[toc] | [prev] | [next] | [standalone]

#1706816

On Tue, 2017-08-08 at 18:50 +0200, Mike Galbraith wrote:
> On Tue, 2017-08-08 at 09:44 -0700, Greg KH wrote:
> > 
> > Should these go back farther than 4.12?  Looks like they apply cleanly
> > to 4.9, didn't look older than that...
> 
> I met prerequisites at 4.11...

FWIW, I took/modified 2d0364c8c1a9.  Dunno if the suspend regression
exists in 4.11 though, without which you'll likely want nothing.

	-Mike

[toc] | [prev] | [next] | [standalone]

#1706817

On 08/08/2017 12:33 PM, Mike Galbraith wrote:
> On Tue, 2017-08-08 at 18:50 +0200, Mike Galbraith wrote:
>> On Tue, 2017-08-08 at 09:44 -0700, Greg KH wrote:
>>>
>>> Should these go back farther than 4.12?  Looks like they apply cleanly
>>> to 4.9, didn't look older than that...
>>
>> I met prerequisites at 4.11...
> 
> FWIW, I took/modified 2d0364c8c1a9.  Dunno if the suspend regression
> exists in 4.11 though, without which you'll likely want nothing.

It does exist, the only change here is that we default people to
scsi-mq in 4.12+. Honestly, nobody complained since we've had scsi-mq,
so I could pivot both ways on whether we really need the changes in
earlier versions or not.

-- 
Jens Axboe

[toc] | [prev] | [next] | [standalone]

#1706748

On 08/08/2017 10:22 AM, 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...

You can add those two commits to stable.

-- 
Jens Axboe

[toc] | [prev] | [next] | [standalone]

#1706749

Could you queue "block: disable runtime-pm for blk-mq" too please? It is also 
related to suspend-resume freezes that were observed by multiple users.

Thanks.

On úterý 8. srpna 2017 18:33:29 CEST Jens Axboe wrote:
> On 08/08/2017 10:22 AM, 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...
> 
> You can add those two commits to stable.

[toc] | [prev] | [next] | [standalone]

#1706753

On Tue, Aug 08, 2017 at 06:36:01PM +0200, Oleksandr Natalenko wrote:
> Could you queue "block: disable runtime-pm for blk-mq" too please? It is also 
> related to suspend-resume freezes that were observed by multiple users.

What is the git commit id of that patch?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1706759

Greg,

this is 765e40b675a9566459ddcb8358ad16f3b8344bbe.

On úterý 8. srpna 2017 18:43:33 CEST Greg KH wrote:
> On Tue, Aug 08, 2017 at 06:36:01PM +0200, Oleksandr Natalenko wrote:
> > Could you queue "block: disable runtime-pm for blk-mq" too please? It is
> > also related to suspend-resume freezes that were observed by multiple
> > users.
> What is the git commit id of that patch?
> 
> thanks,
> 
> greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web