all fixes pushed!

[Paolo Valente]

Hi,
this is just to tell you that I have finally made it to push all recent bug fixes to all active branches: bfq-v8-v4.4, bfq-v8-v4.9, bfq-mq. As for mainline bfq, I have already submitted the same fixes on the linux-block ml. If I have forgotten something (what a surprise it would be), just let me know.

Next step will be to (finally!) apply Lee's patches. Unless some new cataclysm ...

Thanks,
Paolo

[post-factum]

Shall we have BFQ-SQ for 4.12 as a separate patchset?

субота, 29 липня 2017 р. 14:27:32 UTC+2 користувач paolo написав:

[Alt]

Branch bfq-v8-v4.11 don't have 3 commits past "BFQ-v8r12"

[Philip Müller]

Hi all,

I'm a little confused. Lately people posted some issues with resume from RAM when CONFIG_SCSI_MQ_DEFAULT is set to 'y'. In regard of patches, for example for v4.9 I used all till 7994bcf. So I see followed patches added to that branch:

1. block, bfq: consider also in_service_entity to state whether an entit…

2. block, bfq: reset in_service_entity if it becomes idle

3. Add extra checks related to entity scheduling

When I compare pf4 and pf5 I get this: https://github.com/pfactum/pf-kernel/compare/v4.12-pf4...pf-4.12

Are all patches needed or only these:

	blk-mq: Include all present CPUs in the default queue mapping
	blk-mq: Create hctx for each present CPU

[post-factum]

You need blk-mq fixes as well for suspend-to-ram issue to be fixed.

понеділок, 31 липня 2017 р. 19:42:18 UTC+2 користувач Philip Müller написав:

[Paolo Valente]

> Il giorno 31 lug 2017, alle ore 19:08, Alt <alt...@gmail.com> ha scritto:
>
>
> Branch bfq-v8-v4.11 don't have 3 commits past "BFQ-v8r12"
>

Pushed, thanks.

Paolo


> --
> You received this message because you are subscribed to the Google Groups "bfq-iosched" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bfq-iosched...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Paolo Valente]

> Il giorno 29 lug 2017, alle ore 19:50, post-factum <pfa...@gmail.com> ha scritto:
>
> Shall we have BFQ-SQ for 4.12 as a separate patchset?
>

Development beyond 4.11 is now occurring, unified, in the bfq-mq branch. As I wrote some email ago, unfortunately I skipped 4.12 in that branch. Yet, Philip offered to help. I'm about to give him what he needs to make a backport from 4.13.

Thanks,
Paolo

[post-factum]

Okay. Actually, I believe this is not relevant for me anymore since it looks like -mq works well now. Thanks anyway.

вівторок, 1 серпня 2017 р. 08:07:08 UTC+2 користувач paolo написав:

[Philip Müller]

Hi Paolo,

I'm more then happy to help you out. Just write me an email with steps needed to be done.

[Philip Müller]

@post-factum: can you post me a list of all needed commits to fix this issue

[post-factum]

So far, I have these meaningfully related commits in my fixes-4.12 branch:

a6e5722e54c8 block, bfq: boost throughput with flash-based non-queueing devices

b5b1c5fa9219 block,bfq: refactor device-idling logic

0c67fe05da26 blk-mq: Create hctx for each present CPU

90c365ea0712 blk-mq: Include all present CPUs in the default queue mapping

cdfeba9df845 block, bfq: reset in_service_entity if it becomes idle

1fce2ee66f65 block, bfq: consider also in_service_entity to state whether an entity is active

512e1995c5d2 block: disable runtime-pm for blk-mq

fd599d590a45 bfq: dispatch request to prevent queue stalling after the request completion

ab5ec92a3224 bfq: fix typos in comments about B-WF2Q+ algorithm

a6ffda616ada bfq-iosched: fix NULL ioc check in bfq_get_rq_private

049c9dd7fa54 block, bfq: don't change ioprio class for a bfq_queue on a service tree

481bca0848c3 block, bfq: update wr_busy_queues if needed on a queue split

субота, 5 серпня 2017 р. 12:13:40 UTC+2 користувач Philip Müller написав:

[Matthew Alex]

Any hopes for these to be brought to the android implementation?

[Paolo Valente]

> Il giorno 07 ago 2017, alle ore 16:53, Matthew Alex <matthew...@gmail.com> ha scritto:
>
> Any hopes for these to be brought to the android implementation?
>

They are already in 4.4 and 4.9 branches. No older-kernel support for the moment :(

Thanks,
Paolo

[Paolo Valente]

> Il giorno 05 ago 2017, alle ore 12:08, Philip Müller <phil...@gmail.com> ha scritto:
>
> Hi Paolo,
>
> I'm more then happy to help you out. Just write me an email with steps needed to be done.
>

I had sent you the few instructions needed in the other thread where you offered to help. Anyway, here they are again:

Maybe it's enough that I share the branch in question, which you can now find here:
https://github.com/linusw/linux-bfq/tree/bfq-mq-v4.11

Recall that it is only intended as a support for your port, and, for example, it is not in sync with the last fixes (you find everything in the branch bfq-mq). I'll remove it as soon as you have finished.

Thanks,
Paolo

[Hector Martin]

On Saturday, July 29, 2017 at 9:27:32 PM UTC+9, paolo wrote:

Hi,
this is just to tell you that I have finally made it to push all recent bug fixes to all active branches: bfq-v8-v4.4, bfq-v8-v4.9, bfq-mq. As for mainline bfq, I have already submitted the same fixes on the linux-block ml. If I have forgotten something (what a surprise it would be), just let me know.

Any chance the mainline bfq fixes will be submited to the stable kernel series (4.12.x)? Now that bfq is in mainline the fixes should be staged in the linux-stable branch, especially any hard crash/lockup fixes. I have a server running 4.12.10 and getting hard lockups in __bfq_deactivate_entity and it seems these patches should help. I'm testing now with them manually applied, but it would make sense to have them merged into the tree so future stable minor releases get them.

[Paolo Valente]

Definitely. Unfortunately, I don't know who decides which fixes do get back ported to stable kernels and basing on what. Would you like to try to discover it yourself, and share what you find with us?

[Hector Martin "marcan"]

On September 3, 2017 5:03:53 PM GMT+09:00, 'Paolo Valente' via bfq-iosched

>Definitely. Unfortunately, I don't know who decides which fixes do get
>back ported to stable kernels and basing on what. Would you like to try
>to discover it yourself, and share what you find with us?

You do :-)

When submitting a patch back to mainline, you can put "Cc: sta...@vger.kernel.org" in the commit message and it automatically gets submitted to the stable queue once it is merged upstream. Alternatively, you can send mail directly referencing the upstream commit ID in Linus' tree. The rules for what is allowed are here: https://www.kernel.org/doc/html/v4.12/process/stable-kernel-rules.html

So basically, anything that is an oops/panic/hang fix qualifies as long as the fix isn't too convoluted. Given this is a new scheduler in 4.12 I imagine the rules skew in your favor, since nobody is using it by default and obviously if it's broken it should be fixed and the fixes won't affect anything else. I doubt you'll have much trouble getting the fixes submitted. If there's an issue I'm sure Greg will have comments for you.
--
Hector Martin "marcan" (mar...@marcan.st)
Public key: https://mrcn.st/pub