linux-kernel - Re: [PATCH 0/2] Add BLK_FEAT_READ_SYNCHRONOUS and SWP_READ_SYNCHRONOUS

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Zwoh8DrKgSD99xVQ@casper.infradead.org>
Date: Sat, 12 Oct 2024 08:14:56 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Qun-wei Lin (林群崴) <Qun-wei.Lin@...iatek.com>
Cc: "ying.huang@...el.com" <ying.huang@...el.com>,
	Andrew Yang (楊智強) <Andrew.Yang@...iatek.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"baohua@...nel.org" <baohua@...nel.org>,
	"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	wsd_upstream <wsd_upstream@...iatek.com>,
	"david@...hat.com" <david@...hat.com>,
	"schatzberg.dan@...il.com" <schatzberg.dan@...il.com>,
	Chinwen Chang (張錦文) <chinwen.chang@...iatek.com>,
	John Hsu (許永翰) <John.Hsu@...iatek.com>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"axboe@...nel.dk" <axboe@...nel.dk>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"kasong@...cent.com" <kasong@...cent.com>,
	Casper Li (李中榮) <casper.li@...iatek.com>,
	"chrisl@...nel.org" <chrisl@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"ryan.roberts@....com" <ryan.roberts@....com>
Subject: Re: [PATCH 0/2] Add BLK_FEAT_READ_SYNCHRONOUS and
 SWP_READ_SYNCHRONOUS_IO

On Fri, Oct 11, 2024 at 09:08:10AM +0000, Qun-wei Lin (林群崴) wrote:
> The primary motivation for these new feature flags is to handle
> scenarios where we want read operations to be completed within the
> submit context, while write operations are handled in a different
> context.
> 
> This does not necessarily imply that the write operations are slow;
> rather, it is about optimizing the handling of read and write
> operations based on their specific characteristics and requirements.

So why wouldn't we always want to do that instead of making it a
per-bdev flag?