All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fengguang Wu <fengguang.wu@intel.com>
To: YingHang Zhu <casualfisher@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
	akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: readahead: remove redundant ra_pages in file_ra_state
Date: Thu, 25 Oct 2012 10:38:08 +0800	[thread overview]
Message-ID: <20121025023808.GA23462@localhost> (raw)
In-Reply-To: <CAA9v8mEULAEHn8qSsFokEue3c0hy8pK8bkYB+6xOtz_Tgbp0vw@mail.gmail.com>

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?

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. 

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>

WARNING: multiple messages have this Message-ID (diff)
From: Fengguang Wu <fengguang.wu@intel.com>
To: YingHang Zhu <casualfisher@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
	akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: readahead: remove redundant ra_pages in file_ra_state
Date: Thu, 25 Oct 2012 10:38:08 +0800	[thread overview]
Message-ID: <20121025023808.GA23462@localhost> (raw)
In-Reply-To: <CAA9v8mEULAEHn8qSsFokEue3c0hy8pK8bkYB+6xOtz_Tgbp0vw@mail.gmail.com>

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?

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. 

Thanks,
Fengguang

  parent reply	other threads:[~2012-10-25  2:38 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-23 12:46 [PATCH] mm: readahead: remove redundant ra_pages in file_ra_state Ying Zhu
2012-10-23 12:46 ` Ying Zhu
2012-10-23 13:21 ` Ni zhan Chen
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-23 13:41       ` YingHang Zhu
2012-10-24  1:02       ` Ni zhan Chen
2012-10-24  1:02         ` Ni zhan Chen
2012-10-24  1:33         ` YingHang Zhu
2012-10-24  1:33           ` YingHang Zhu
2012-10-23 22:47 ` Dave Chinner
2012-10-23 22:47   ` Dave Chinner
2012-10-23 23:53   ` YingHang Zhu
2012-10-23 23:53     ` YingHang Zhu
2012-10-24 20:19     ` Dave Chinner
2012-10-24 20:19       ` Dave Chinner
2012-10-25  0:17       ` YingHang Zhu
2012-10-25  0:17         ` YingHang Zhu
2012-10-25  1:48         ` Ni zhan Chen
2012-10-25  1:48           ` Ni zhan Chen
2012-10-25  1:50         ` Dave Chinner
2012-10-25  1:50           ` Dave Chinner
2012-10-25  2:04           ` YingHang Zhu
2012-10-25  2:04             ` YingHang Zhu
2012-10-25  2:12             ` Ni zhan Chen
2012-10-25  2:12               ` Ni zhan Chen
2012-10-25  2:31               ` YingHang Zhu
2012-10-25  2:31                 ` YingHang Zhu
2012-10-25  2:58               ` Fengguang Wu
2012-10-25  2:58                 ` Fengguang Wu
2012-10-25  3:12                 ` YingHang Zhu
2012-10-25  3:12                   ` YingHang Zhu
2012-10-26  0:25                 ` Dave Chinner
2012-10-26  0:25                   ` Dave Chinner
2012-10-26  1:27                   ` Fengguang Wu
2012-10-26  1:27                     ` Fengguang Wu
2012-10-26  2:30                     ` Ni zhan Chen
2012-10-26  2:30                       ` Ni zhan Chen
2012-10-26  3:28                       ` YingHang Zhu
2012-10-26  3:28                         ` YingHang Zhu
2012-10-26  3:51                         ` Ni zhan Chen
2012-10-26  3:51                           ` Ni zhan Chen
2012-10-26  4:35                           ` YingHang Zhu
2012-10-26  4:35                             ` YingHang Zhu
2012-10-26  6:58                       ` Fengguang Wu
2012-10-26  6:58                         ` Fengguang Wu
2012-10-26  7:03                         ` Ni zhan Chen
2012-10-26  7:03                           ` Ni zhan Chen
2012-10-26  7:09                           ` Fengguang Wu
2012-10-26  7:09                             ` Fengguang Wu
2012-10-26  7:19                             ` Ni zhan Chen
2012-10-26  7:19                               ` Ni zhan Chen
2012-10-26  7:36                               ` Fengguang Wu
2012-10-26  7:36                                 ` Fengguang Wu
2012-10-26  7:47                                 ` Ni zhan Chen
2012-10-26  7:47                                   ` Ni zhan Chen
2012-10-26  8:02                                   ` Fengguang Wu
2012-10-26  8:02                                     ` Fengguang Wu
2012-10-26  8:08                                     ` Ni zhan Chen
2012-10-26  8:08                                       ` Ni zhan Chen
2012-10-26  8:13                                     ` YingHang Zhu
2012-10-26  8:13                                       ` YingHang Zhu
2012-10-26  2:25                   ` Ni zhan Chen
2012-10-26  2:25                     ` Ni zhan Chen
2012-10-26  3:38                   ` YingHang Zhu
2012-10-26  3:38                     ` YingHang Zhu
2012-10-26  3:55                     ` Fengguang Wu
2012-10-26  3:55                       ` Fengguang Wu
2012-10-26  5:00                       ` YingHang Zhu
2012-10-26  5:00                         ` YingHang Zhu
2012-10-25  2:38             ` Fengguang Wu [this message]
2012-10-25  2:38               ` Fengguang Wu
2012-10-25  3:08               ` YingHang Zhu
2012-10-25  3:08                 ` YingHang Zhu

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=20121025023808.GA23462@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=casualfisher@gmail.com \
    --cc=david@fromorbit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.