From: YingHang Zhu <casualfisher@gmail.com>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH] mm: readahead: remove redundant ra_pages in file_ra_state
Date: Thu, 25 Oct 2012 11:08:18 +0800 [thread overview]
Message-ID: <CAA9v8mFDP8NTfgoL9tVt2FNAGa13t+0tAUrWvTqt2G-RmEki9A@mail.gmail.com> (raw)
In-Reply-To: <20121025023808.GA23462@localhost>
On Thu, Oct 25, 2012 at 10:38 AM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> Hi YingHang,
>
>> Actually I've talked about it with Fengguang, he advised we should unify the
>> ra_pages in struct bdi and file_ra_state and leave the issue that
>> spreading data
>> across disks as it is.
>> Fengguang, what's you opinion about this?
>
> Yeah the two ra_pages may run out of sync for already opened files,
> which could be a problem for long opened files. However as Dave put
> it, a device's max readahead size is typically a static value that can
> be set at mount time. So, the question is: do you really hurt from the
> old behavior that deserves this code change?
We could advise the above application to reopen files.
As I mentioned previously the many scst users also have this problem:
[quote]
Note2: you need to restart SCST after you changed read-ahead settings
on the target. It is a limitation of the Linux read ahead
implementation. It reads RA values for each file only when the file
is open and not updates them when the global RA parameters changed.
Hence, the need for vdisk to reopen all its files/devices.
[/quote]
So IMHO it's a functional bug in kernel that brings inconvenience to the
application developers.
>
> I agree with Dave that the multi-disk case is not a valid concern. In
> fact, how can the patch help that case? I mean, if it's two fuse files
> lying in two disks, it *was* not a problem at all. If it's one big
> file spreading to two disks, it's a too complex scheme to be
> practically manageable which I doubt if you have such a setup.
Yes this patch does not solve the issue here. I'm just push the discussion
a little further, in reality we may never meet such setup.
Thanks,
Ying Hang
>
> Thanks,
> Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2012-10-25 3:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 12:46 Ying Zhu
2012-10-23 13:21 ` Ni zhan Chen
[not found] ` <CAA9v8mGMa3SDD1OLTG_wdhCGx7K-0kvSV1+MRi9uCGTz6zZaLg@mail.gmail.com>
2012-10-23 13:41 ` YingHang Zhu
2012-10-24 1:02 ` Ni zhan Chen
2012-10-24 1:33 ` YingHang Zhu
2012-10-23 22:47 ` Dave Chinner
2012-10-23 23:53 ` YingHang Zhu
2012-10-24 20:19 ` Dave Chinner
2012-10-25 0:17 ` YingHang Zhu
2012-10-25 1:48 ` Ni zhan Chen
2012-10-25 1:50 ` Dave Chinner
2012-10-25 2:04 ` YingHang Zhu
2012-10-25 2:12 ` Ni zhan Chen
2012-10-25 2:31 ` YingHang Zhu
2012-10-25 2:58 ` Fengguang Wu
2012-10-25 3:12 ` YingHang Zhu
2012-10-26 0:25 ` Dave Chinner
2012-10-26 1:27 ` Fengguang Wu
2012-10-26 2:30 ` Ni zhan Chen
2012-10-26 3:28 ` YingHang Zhu
2012-10-26 3:51 ` Ni zhan Chen
2012-10-26 4:35 ` YingHang Zhu
2012-10-26 6:58 ` Fengguang Wu
2012-10-26 7:03 ` Ni zhan Chen
2012-10-26 7:09 ` Fengguang Wu
2012-10-26 7:19 ` Ni zhan Chen
2012-10-26 7:36 ` Fengguang Wu
2012-10-26 7:47 ` Ni zhan Chen
2012-10-26 8:02 ` Fengguang Wu
2012-10-26 8:08 ` Ni zhan Chen
2012-10-26 8:13 ` YingHang Zhu
2012-10-26 2:25 ` Ni zhan Chen
2012-10-26 3:38 ` YingHang Zhu
2012-10-26 3:55 ` Fengguang Wu
2012-10-26 5:00 ` YingHang Zhu
2012-10-25 2:38 ` Fengguang Wu
2012-10-25 3:08 ` YingHang Zhu [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=CAA9v8mFDP8NTfgoL9tVt2FNAGa13t+0tAUrWvTqt2G-RmEki9A@mail.gmail.com \
--to=casualfisher@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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