linux-ext4 - Re: [PATCH] ext4: introduce per-inode DAX flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170811134130.o46y5jpekrpj5qvw@rh_laptop>
Date:   Fri, 11 Aug 2017 15:41:30 +0200
From:   Lukas Czerner <lczerner@...hat.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: introduce per-inode DAX flag

On Fri, Aug 11, 2017 at 05:58:49AM -0700, Christoph Hellwig wrote:
> 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.

I understand your concept, I even agree that application should not
even know, or have to know, about DAX, or any characteristics of the
medium. Application can take advantage of madvise/fadvise hints, if
implemented in this case and it will be usefull. But I am not talking
about the application here.

Administrator is the one setting up the environment and no matter what
are the capabilities of the application he (it) can and should have the
information about the the system (and the medium characteristics) and
should be able to tweak it. Per inode DAX flags give him the ability to
do so permanently in a convenient way in this case.

We have plenty of knobs in the file system we can play with to optimize
it for a given medium already. Sometimes we maybe go too far, but I do not
think it's the case here. Especially since I do not see a way to implement
the above mentioned use case in a different way - without relying on the
application to do the right thing with hints (when those are implemented).

-Lukas