Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS, &purged, &ret);Another reason to make it hard is that madvise(2) is tight coupled with with vmas split/merge. It needs mmap_sem's write-side lock and it hurt anon-vrange test performance much heavily and userland might want to make volatile range with small unit like "page size" so it's undesireable to make it with vma. Then, we should filter out to avoid vma split/merge in implementation if only MADV_LAZY case? Doable but it could make code complicated and lost consistency with other variant of madvise.
I haven't seen your performance test result. Could please point out URLs? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
