From: Andrew Morton <akpm@linux-foundation.org>
To: Damien Ramonda <damien.ramonda@intel.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
pierre.tardy@intel.com, fengguang.wu@intel.com,
david.a.cohen@intel.com
Subject: Re: [PATCH] readahead: fix sequential read cache miss detection
Date: Thu, 17 Oct 2013 13:23:48 -0700 [thread overview]
Message-ID: <20131017132348.a89c6cb5222eda83fb0ce079@linux-foundation.org> (raw)
In-Reply-To: <1382033352-21225-1-git-send-email-damien.ramonda@intel.com>
On Thu, 17 Oct 2013 20:09:12 +0200 Damien Ramonda <damien.ramonda@intel.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.
prev parent reply other threads:[~2013-10-17 20:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 18:09 Damien Ramonda
2013-10-17 20:23 ` Andrew Morton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131017132348.a89c6cb5222eda83fb0ce079@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=damien.ramonda@intel.com \
--cc=david.a.cohen@intel.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pierre.tardy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®