From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "Johannes.Thumshirn@wdc.com" <Johannes.Thumshirn@wdc.com>,
"hans@owltronix.com" <hans@owltronix.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"slava@dubeyko.com" <slava@dubeyko.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"javier.gonz@samsung.com" <javier.gonz@samsung.com>
Subject: RE: [RFC PATCH] Introduce generalized data temperature estimation framework
Date: Tue, 28 Jan 2025 22:35:23 +0000 [thread overview]
Message-ID: <2583d29cdac09b831e4299248234fe2633a6f45e.camel@ibm.com> (raw)
In-Reply-To: <8369d108-7f11-4989-863f-abccac45c322@wdc.com>
On Tue, 2025-01-28 at 08:59 +0000, Johannes Thumshirn wrote:
> On 28.01.25 09:45, Hans Holmberg wrote:
> > > I think that Direct IO could benefit too. The question here how to account dirty
> > > memory pages and updated memory pages. Currently, I am using
> > > folio_account_dirtied() and folio_clear_dirty_for_io() to implement the
> > > calculation the temperature. As far as I can see, Direct IO requires another
> > > methods of doing this. The rest logic can be the same.
> >
> > It's probably a good idea to cover direct IO as well then as this is
> > intended to be a generalized framework.
>
> Especially given that most applications that really care about data
> lifetimes, write amplification etc are heavy users of direct I/O.
I believe smartphones is really huge use-case. And LFS and GC based file
systems are used there. So, page cache based approach makes sense for such
file systems to manage data placement policy efficiently.
I like this suggestion related to Direct IO case. But it needs to elaborate
the way to proper manage dirty and updated memory pages calculation for
Direct IO case.
Thanks,
Slava.
next prev parent reply other threads:[~2025-01-28 22:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 20:24 Viacheslav Dubeyko
2025-01-24 8:19 ` Johannes Thumshirn
2025-01-24 21:03 ` Viacheslav Dubeyko
2025-01-27 14:19 ` Hans Holmberg
2025-01-27 20:58 ` Viacheslav Dubeyko
2025-01-28 8:45 ` Hans Holmberg
2025-01-28 8:59 ` Johannes Thumshirn
2025-01-28 22:35 ` Viacheslav Dubeyko [this message]
2025-01-28 22:30 ` Viacheslav Dubeyko
2025-01-29 10:23 ` Hans Holmberg
2025-01-30 18:31 ` Viacheslav Dubeyko
2025-02-06 8:00 ` Hans Holmberg
2025-01-25 12:25 ` Jeff Layton
2025-01-27 20:12 ` Viacheslav Dubeyko
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=2583d29cdac09b831e4299248234fe2633a6f45e.camel@ibm.com \
--to=slava.dubeyko@ibm.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=hans@owltronix.com \
--cc=javier.gonz@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=slava@dubeyko.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