linux-kernel - Re: [RESEND] [PATCH] readahead:add blk_run_backing

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: <4A5F032F.40205@vlnb.net>
Date:	Thu, 16 Jul 2009 14:38:39 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	Kurt Garloff <garloff@...e.de>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev


Kurt Garloff, on 07/16/2009 12:52 AM wrote:
> Hi,
> 
> On Wed, Jul 08, 2009 at 04:40:08PM +0400, Vladislav Bolkhovitin wrote:
>> I've also long ago noticed that reading data from block devices is slower 
>> than from files from mounted on those block devices file systems. Can 
>> anybody explain it?
> 
> Brainstorming:
> - block size (reads on the block dev might be done with smaller size)

As we already found out in this and other threads, smaller "block size", 
i.e. each request size, is often means better throughput, sometimes much 
better.

> - readahead (do we use the same RA algo for block devs)
> - page cache might be better optimized than buffer cache?
> 
> Just guesses from someone that has not looked into that area of the
> kernel for a while, so take it with a grain of salt.
> 
> Cheers,
--
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/