From: Andrew Morton <akpm@linux-foundation.org>
To: "\"夷则(Caspar)\"" <jinli.zjl@alibaba-inc.com>
Cc: "Mel Gorman" <mgorman@techsingularity.net>,
green@linuxhacker.ru, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
"\"杨勇(智彻)\"" <zhiche.yy@alibaba-inc.com>,
"\"十刀\"" <shidao.ytt@alibaba-inc.com>
Subject: Re: [PATCH] mm/fadvise: discard partial pages iff endbyte is also eof
Date: Thu, 4 Jan 2018 14:54:39 -0800 [thread overview]
Message-ID: <20180104145439.ab5cca8adbccee4ef54348fa@linux-foundation.org> (raw)
In-Reply-To: <be7778b9-58de-3717-0da5-e88fc5ec5542@alibaba-inc.com>
On Thu, 04 Jan 2018 16:17:50 +0800 "a?.a??(Caspar)" <jinli.zjl@alibaba-inc.com> wrote:
> > So, thinking caps on: why not just discard them? After all, that's
> > what userspace asked us to do.
>
> Hi Andrew, I doubt if "just discard them" is a proper action to match
> the userspace's expectation. Maybe we will never meet the userspace's
> expectation since we are doing pages in kernel while userspace is
> passing bytes offset/length to the kernel. Note that Mel Gorman has
> already documented page-unaligned behaviors in posix_fadvise() man
> page[1] but obviously not all people (including /me) are able to read
> the _latest_ version, so someone might still uses the syscall with page
> unaligned offset/length. The userspace might only ask for discarding
> certain *bytes*, instead of *pages*.
>
> And I think we need to look back first why we thought "preserved is
> better than discard". If we throw the whole page, the rest part of the
> page might still be required (consider the offset and length is in the
> middle of a file) because it's untagged:
>
> ...|------------ PAGE --------------|...
> ...| DONTNEED |------ UNTAGGED -----|...
>
> but the page has gone, page fault occurs and we need to reload it from
> the disk -- performance degradation happens.
>
> Maybe that's why we would rather preserv the whole page before.
>
> But if we don't throw the partial page at all, and if the tail partial
> page is _exactly the end of the file_, a page that advised to be NONEED
> would be left in memory. And we all know that it is safe to throw it.
>
> So we come up with this patch -- to keep the partial page not been
> throwing away, and add a special case when the partial page is the end
> of the file, we can throw it safely. I guess it might be a better solution.
OK, that makes sense.
As Mel (sort of) said, "delete part of page" can mean "I want to retain
the other part of the page". So we should retain the page. But for
end-of-file, there is no "other part of the page".
> One thing I'm worrying about is that, this patch might lead to a new
> undocumented behavior, so maybe we need to document this special case in
> posix_fadvise() man page too? hmmm...
That wouldn't hurt.
Could you please resend the patch with the changelog updated to reflect
this discussion?
--
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>
next prev parent reply other threads:[~2018-01-04 22:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-23 4:16 十刀
2018-01-03 6:53 ` 夷则(Caspar)
2018-01-03 10:48 ` Mel Gorman
2018-01-04 0:17 ` Andrew Morton
2018-01-04 8:17 ` 夷则(Caspar)
2018-01-04 22:54 ` Andrew Morton [this message]
2018-01-04 10:05 ` Mel Gorman
2018-01-04 6:13 ` 夷则(Caspar)
2018-01-04 7:44 ` 夷则(Caspar)
2018-01-04 11:34 ` Mel Gorman
2018-01-04 11:38 ` 夷则(Caspar)
2018-01-05 6:10 ` [PATCH v2] mm/fadvise: discard partial page if endbyte is also EOF 夷则(Caspar)
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=20180104145439.ab5cca8adbccee4ef54348fa@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=green@linuxhacker.ru \
--cc=jinli.zjl@alibaba-inc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=shidao.ytt@alibaba-inc.com \
--cc=zhiche.yy@alibaba-inc.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