linux-kernel - Re: Regarding patch "block/blk-mq: Don't complete locally if capacities are different"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <12a6f001-813e-4bc4-90c2-9f9ef7dc72e6@acm.org>
Date: Wed, 21 Aug 2024 10:22:09 -0700
From: Bart Van Assche <bvanassche@....org>
To: MANISH PANDEY <quic_mapa@...cinc.com>,
 Sandeep Dhavale <dhavale@...gle.com>,
 Dietmar Eggemann <dietmar.eggemann@....com>
Cc: Qais Yousef <qyousef@...alina.io>,
 Christian Loehle <christian.loehle@....com>, axboe@...nel.dk,
 mingo@...nel.org, peterz@...radead.org, vincent.guittot@...aro.org,
 linux-block@...r.kernel.org, sudeep.holla@....com,
 Jaegeuk Kim <jaegeuk@...nel.org>, Christoph Hellwig <hch@...radead.org>,
 kailash@...gle.com, tkjos@...gle.com, bvanassche@...gle.com,
 quic_nitirawa@...cinc.com, quic_cang@...cinc.com, quic_rampraka@...cinc.com,
 quic_narepall@...cinc.com,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Regarding patch "block/blk-mq: Don't complete locally if
 capacities are different"

On 8/21/24 5:29 AM, MANISH PANDEY wrote:
> How about introducing a new rq_affinity ( may be rq_affinity = 3) for 
> using cpus_equal_capacity() using new flag QUEUE_FLAG_SAME_CAPACITY.
> 
> if (cpu == rq->mq_ctx->cpu ||
>      (!test_bit(QUEUE_FLAG_SAME_FORCE, &rq->q->queue_flags) &&
>        cpus_share_cache(cpu, rq->mq_ctx->cpu) &&
> +      (test_bit(QUEUE_FLAG_CPU_CAPACITY, &rq->q->queue_flags))
>         && cpus_equal_capacity(cpu, rq->mq_ctx->cpu)))
>          return false;
> 
> Could you please consider raising similar change, if this seems fine for 
> all.

I'm not sure that a change like the above would be acceptable.

What is the performance impact of the above change? Redirecting
completion interrupts from a slow core to a fast core causes additional
cache misses if the I/O was submitted from a slow core. Are there
perhaps use cases for which the above change slows down I/O?

Thanks,

Bart.