linux-kernel - Re: [PATCH] readahead even for FMODE

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: <20100402065917.GX23510@kernel.dk>
Date:	Fri, 2 Apr 2010 08:59:17 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] readahead even for FMODE_RANDOM

On Fri, Apr 02 2010, Wu Fengguang wrote:
> On Fri, Apr 02, 2010 at 02:38:30PM +0800, Jens Axboe wrote:
> > On Fri, Apr 02 2010, Wu Fengguang wrote:
> > > Hi Jens,
> > > 
> > > On Fri, Apr 02, 2010 at 02:31:51AM +0800, Jens Axboe wrote:
> > > > Hi,
> > > > 
> > > > I got a problem report with fio where larger block size random reads
> > > > where markedly slower with buffered IO than with O_DIRECT, and the
> > > > initial thought was that perhaps this was some fio oddity. The reporter
> > > > eventually discovered that turning off the fadvise hint made it work
> > > > fine. So I took a look, and it seems we never do readahead for
> > > > FMODE_RANDOM even if the request size is larger than 1 page. That seems
> > > > like a bug, if an application is doing eg 16kb random reads, you want to
> > > > readahead the 12kb remaining data. On devices where smaller transfer
> > > > sizes are slower than larger ones, this can make a large difference.
> > > > 
> > > > This patch makes us readahead even for FMODE_RANDOM, iff we'll be
> > > > reading more pages in that single read. I ran a quick test here, and it
> > > > appears to fix the problem (no difference with fadvise POSIX_FADV_RANDOM
> > > > being passed in or not).
> > >  
> > > I guess the application is doing (at least partial) sequential reads,
> > > while at the same time tell kernel with POSIX_FADV_RANDOM that it's
> > > doing random reads.
> > > 
> > > If so, it's mainly the application's fault.
> > 
> > The application is doing large random reads. It's purely random, so
> > the POSIX_FADV_RANDOM hint is correct. However, thinking about it, it
> 
> How large is it? For random reads > read_ahead_kb,
> ondemand_readahead() will break it into read_ahead_kb sized IOs, while
> force_page_cache_readahead() won't. That may impact IO performance.

The test case was 128kb random reads. So should still be within the
normal read_ahead_kb. I suspect the reporter would not have noticed if
the issue size was as large as read_ahead_kb even if the request size
was larger, the problem was that he ended up seeing 4kb ios only.

> > may be that we later hit a random "block" that has now been cached due
> > to this read-ahead. Let me try and rule that out completely and see if
> > there's still the difference. The original reporter observed 4kb reads
> > hitting the driver, where 128kb was expected.
> 
> 4kb reads hit the disk (on POSIX_FADV_RANDOM)? That sounds like
> behavior in pre .34 kernels that is fixed by commit 0141450f66c:
> 
>     readahead: introduce FMODE_RANDOM for POSIX_FADV_RANDOM

Could explain why I'm not reproducing when doing a quick test on the
laptop. It is an older kernel. So it could be that I'm just imaging the
issue on the current kernel, I don't have hard data to back it up on
that version.

So disregard the patch for now, part-sequential behaviour on
POSIX_FADV_RANDOM isn't the issue here.

-- 
Jens Axboe

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