On Tue 09-10-18 15:43:41, Jeff Moyer wrote:
Jan Kara <jack(a)suse.cz> writes:
> commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax"
> removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
> mean time certain customer of ours started poking into /proc/<pid>/smaps
> and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA
> flags, the application just fails to start complaining that DAX support is
> missing in the kernel. The question now is how do we go about this?
> Strictly speaking, this is a userspace visible regression (as much as I
> think that application poking into VMA flags at this level is just too
> bold). Is there any precedens in handling similar issues with smaps which
> really exposes a lot of information that is dependent on kernel
> implementation details?
> I have attached a patch that is an obvious "fix" for the issue - just
> VM_MIXEDMAP flag in smaps. But I'm open to other suggestions...
I'm intrigued by the use case. Do I understand you correctly that the
database in question does not intend to make data persistent from
userspace? In other words, fsync/msync system calls are being issued by
Yes, at least at the initial stage, they use fsync / msync to persist data.
I guess what I'm really after is a statement of requirements or
expectations. It would be great if you could convince the database
developer to engage in this discussion directly.
So I talked to them and what they really look after is the control over the
amount of memory needed by the kernel. And they are right that if your
storage needs page cache, the amount of memory you need to set aside for the
kernel is larger.
Jan Kara <jack(a)suse.com>
SUSE Labs, CR