linux-kernel - Re: [PATCH 1/17] cramfs: use read_mapping

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: <5c49b0ed0704121136uce5b15ah3004cd19e44994f3@mail.gmail.com>
Date:	Thu, 12 Apr 2007 11:36:42 -0700
From:	"Nate Diller" <nate.diller@...il.com>
To:	"Roman Zippel" <zippel@...ux-m68k.org>
Cc:	"Christoph Hellwig" <hch@...radead.org>,
	"Andrew Morton" <akpm@...l.org>,
	"Alexander Viro" <viro@...iv.linux.org.uk>,
	"Mikulas Patocka" <mikulas@...ax.karlin.mff.cuni.cz>,
	"David Woodhouse" <dwmw2@...radead.org>,
	"Dave Kleikamp" <shaggy@...tin.ibm.com>,
	"Anton Altaparmakov" <aia21@...tab.net>,
	"Evgeniy Dushistov" <dushistov@...l.ru>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	reiserfs-dev@...esys.com
Subject: Re: [PATCH 1/17] cramfs: use read_mapping_page

On 4/12/07, Roman Zippel <zippel@...ux-m68k.org> wrote:
> Hi,
>
> On Thu, 12 Apr 2007, Christoph Hellwig wrote:
>
> > On Wed, Apr 11, 2007 at 07:49:38PM -0700, Nate Diller wrote:
> > > read_mapping_page_async() is going away, so convert its only user to
> > > read_mapping_page().  This change has not been benchmarked, however, in
> > > order to get real parallelism this wants something completely different,
> > > like __do_page_cache_readahead(), which is not currently exported.
> >
> > Why is read_mapping_page_async going away?  This probably needs a lot more
> > testing, and I'd be much happier if you split it out of the series and
> > sent it separately at the end.
>
> That function wasn't fully async anyway, as it would often sleep in
> lock_page(). AFAICT only in the special case of a partial written page
> would this function return a not yet uptodate page.

yes, exactly, the structure of read_cache_page() and friends is
totally not appropriate for doing async I/O to more than one page at a
time, and the whole point of the special treatment in cramfs was to
read 4 pages at once rather than synchronously reading each of the 4
seperately.  read_cache_page_async() is totally wrong for that use,
its purpose would be to get a reference to a single page that is
likely to be in cache already without having to take the page_lock.
Turns out nobody needs to do that, so there's no point in keeping it
around.

If the performance gain of reading all 4 pages at once would be worth
the effort, this code should be using __do_page_cache_readahead().
That function allocates all the pages first, then reads them in
asynchronously as a group.  It is currently not exported.

NATE
-
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/