All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@infradead.org>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: introduce per-inode DAX flag
Date: Fri, 11 Aug 2017 05:58:49 -0700	[thread overview]
Message-ID: <20170811125849.GA15300@infradead.org> (raw)
In-Reply-To: <20170811121132.bj5y77scrvkgy7uo@rh_laptop>

On Fri, Aug 11, 2017 at 02:11:32PM +0200, Lukas Czerner wrote:
> Thanks, for the answer. I do not know too much about the DAX enabled HW.
> However I do know that there is some variety to it, some can be faster
> than DRAM, some can be slower, or on-par with DRAM. Some can be more
> expensive, hence probably smaller, some cheaper and bigger. What about
> latency and throughput can there be difference as well ?

Or it could be similar for reads and much slower for writes.  Or it
might prefer larger access sizes than a cache line.

> That said, it seems to me that there can be some user choice involved in
> this at least based on the fact that when DAX is used system memory is not
> used.

All of the above are charateristics of the medium, not of the
application.


> So for example when DAX HW is slower than system memory, user can make
> a choice to exclude some inodes to speed up particular workload, while
> saving system memory where it does not matter as much.

What should be factored into the decision might be access hints from
the applications, which would be things like madvise/fadvise hints.

But the application should not even have to know about something like
DAX, and the detailed access characterisics of the medium.  And even
more importantly we should not encode those complex characterisitcs
(see above) into a binary flag in the on-disk format.

  reply	other threads:[~2017-08-11 12:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 16:09 [PATCH] ext4: introduce per-inode DAX flag Lukas Czerner
2017-08-05  8:46 ` Christoph Hellwig
2017-08-07 12:12   ` Lukas Czerner
2017-08-08  9:00     ` Lukas Czerner
2017-08-11 10:01       ` Christoph Hellwig
2017-08-11 12:11         ` Lukas Czerner
2017-08-11 12:58           ` Christoph Hellwig [this message]
2017-08-11 13:41             ` Lukas Czerner
2017-08-24 18:20               ` Theodore Ts'o
2017-08-25  7:54                 ` Christoph Hellwig
2017-08-25 15:14                   ` Theodore Ts'o
2017-08-25 15:40                     ` Christoph Hellwig
2017-08-25 16:28                       ` Theodore Ts'o
2017-08-25 23:33                       ` Dave Chinner
2017-08-28  7:38                         ` Christoph Hellwig
2017-08-28 10:10                           ` Dave Chinner
2017-08-29 15:49                             ` Jan Kara
2017-08-29 22:57                               ` Dave Chinner
2017-08-30 10:00                                 ` Jan Kara
2017-08-30 12:34                                   ` Christoph Hellwig
2017-08-30 15:00                                     ` Theodore Ts'o
2017-08-30 15:30                                       ` Lukas Czerner
2017-08-30 15:29                                     ` Jan Kara
2017-08-30 16:05                                   ` Jan Kara

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=20170811125849.GA15300@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.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.