On Thu, Oct 26, 2017 at 8:07 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Thu 26-10-17 07:51:20, Dave Hansen wrote: >> On 10/26/2017 07:31 AM, Michal Hocko wrote: >> > On Thu 26-10-17 07:24:14, Dave Hansen wrote: >> >> Actually, I don't remember whether it was tooling or just confused >> >> humans. I *think* Dan was trying to write test cases for huge page DAX >> >> support and couldn't figure out whether or not it was using large pages. >> > >> > That sounds like a very weak justification to adding new stuff to smaps >> > to be honest. >> >> Yep, agreed. It can't go in _just_ for DAX, and Fan and the other DAX >> folks need to elaborate on their needs here. >> >> Do you have any better ideas? If we did this, we could probably make an >> argument that the AnonHuge fields could go away some day. They haven't >> always been there. > > Yeah, if there is an effective way to see large mappings within the > range then AnonHuge should probably go away. If that is possible due to > userspace regressions... > >> The only other alternative I can think of are truly DAX-specific >> interfaces, which also seem like a really bad idea. > > Well, if this is mostly for debugging purposes then why not? I should have recalled this sooner, but for device-dax we don't need smaps support because the mapping type is enforced by the device. I.e. if you set the alignment to 2MB you are guaranteed to either get PMD mappings or SIGBUS. Filesystem DAX is where things are more dynamic, but because they are dynamic smaps is only an ephemeral answer. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
