linux-kernel - Re: [PATCH] readahead: fix sequential read cache miss detection

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] [day] [month] [year] [list]

Date:	Thu, 17 Oct 2013 13:23:48 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Damien Ramonda <damien.ramonda@...el.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	pierre.tardy@...el.com, fengguang.wu@...el.com,
	david.a.cohen@...el.com
Subject: Re: [PATCH] readahead: fix sequential read cache miss detection

On Thu, 17 Oct 2013 20:09:12 +0200 Damien Ramonda <damien.ramonda@...el.com> wrote:

> The kernel's readahead algorithm sometimes interprets random read
> accesses as sequential and triggers unnecessary data prefecthing
> from storage device (impacting random read average latency).
> 
> In order to identify sequential cache read misses, the readahead
> algorithm intends to check whether offset - previous offset == 1
> (trivial sequential reads) or offset - previous offset == 0
> (sequential reads not aligned on page boundary):
> 
> if (offset - (ra->prev_pos >> PAGE_CACHE_SHIFT) <= 1UL)
> 
> The current offset is stored in the "offset" variable of type
> "pgoff_t" (unsigned long), while previous offset is stored in
> "ra->prev_pos" of type "loff_t" (long long). Therefore,
> operands of the if statement are implicitly converted to type
> long long. Consequently, when previous offset > current offset
> (which happens on random pattern), the if condition is true
> and access is wrongly interpeted as sequential. An unnecessary
> data prefetching is triggered, impacting the average
> random read latency.
> 
> Storing the previous offset value in a "pgoff_t" variable
> (unsigned long) fixes the sequential read detection logic.

Do you have any performance testing results which would permit
people to understand the significance of this change?

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