Hi Jeff, On Tue 09-10-18 15:43:41, Jeff Moyer wrote: > Jan Kara <jack@xxxxxxx> writes: > > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has > > 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 fake > > 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 > the database? 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. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
