linux-kernel - Re: [RFC 1/2] aio: async readahead

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]

Date:	Fri, 19 Sep 2014 04:26:12 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	Milosz Tanski <milosz@...in.com>, linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-aio@...ck.org,
	Mel Gorman <mgorman@...e.de>,
	Volker Lendecke <Volker.Lendecke@...net.de>,
	Tejun Heo <tj@...nel.org>, Jeff Moyer <jmoyer@...hat.com>,
	Andreas Dilger <adilger@...ger.ca>
Subject: Re: [RFC 1/2] aio: async readahead

Requiring the block mappings to be entirely async is why we never went
for full buffered aio.  What would seem more useful is to offload all
readahead to workqueues to make sure they never block the caller for
sys_readahead or if we decide to readahead for the nonblocking read.

I tried to implement this, but I couldn't find a good place to hang
the work_struct for it off.  If we decide to dynamically allocate
the ra structure separate from struct file that might be an obvious
place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/