linux-kernel - RE: [PATCH V2] Consider inflight IO in io accounting for high latency devices

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: <CO1PR10MB4563F2D918EF5BBAD98FC87098D5A@CO1PR10MB4563.namprd10.prod.outlook.com>
Date:   Wed, 18 Oct 2023 18:44:17 +0000
From:   Gulam Mohamed <gulam.mohamed@...cle.com>
To:     Jens Axboe <axboe@...nel.dk>, Bart Van Assche <bvanassche@....org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V2] Consider inflight IO in io accounting for high latency
 devices

-----Original Message-----
From: Jens Axboe <axboe@...nel.dk> 
Sent: Tuesday, October 17, 2023 7:54 PM
To: Gulam Mohamed <gulam.mohamed@...cle.com>; Bart Van Assche <bvanassche@....org>; linux-block@...r.kernel.org; linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] Consider inflight IO in io accounting for high latency devices

On 10/16/23 10:13 PM, Gulam Mohamed wrote:
> Hi Bart,
> 
> Thanks for the review. I agree, for low latency devices if they have 
> single hardware queue, this patch will have significant impact. Can 
> you please let me know about what kind of low latency devices will 
> have a single queue (just for my knowledge)? Also I would be grateful 
> if you have any suggestions to fix this issue?

I mentioned this last time, I'll do it again - please follow normal mailing list etiquette. Don't top post, and don't do those unreadable/unquotable "see replies inline".

As I told you last time as well, the problem with the approach is exactly as Bart says - it's expensive. Because it's expensive, you limit the fix to single queue devices and then hope that this is fine because of some ill perceived notion that single queue devices must be slow, and hence this isn't a big problem. But this both misses the fact that you could very well have single queue devices that are much faster than the one you used to test with. Those do exist.

This doesn't even address the fact that presumably this problem isn't specific to single queue devices at all. You may only care about those, but as a fix, it's lacking as it doesn't apply to devices across the board.

[GULAM]: Thanks Jens for the comments. I thought that most of the faster devices will have more than 1 queue. Sorry for that misinterpretation. Now I understood the issue with the fix here.
I was trying to understand how to fix this issue. Can you please provide your suggestions?

--
Jens Axboe