[lkml]   [2013]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] readahead: fix sequential read cache miss detection
On Thu, 17 Oct 2013 20:09:12 +0200 Damien Ramonda <> 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?


 \ /
  Last update: 2013-10-17 22:41    [W:0.026 / U:1.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site