On Thu, 17 Oct 2013 20:09:12 +0200 Damien Ramonda <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
