Sorry for the late response. >> Yes, I propose it as an optional flag for UFFD-WP. >> Anyhow, I believe the UFFD-WP as implemented now is not efficient and >> should’ve been vectored to allow one TLB shootdown for many >> non-consecutive pages. > > Agreed. Would providing a vector of ranges help too for a few uffd ioctls? > > I'm also curious whether you're still actively developing (or running) your > iouring series. So I finished building a prototype some time ago, and one of the benefits was in reducing memory reclamation time. Unfortunately, MGLRU then came and took away a lot of the benefit. A colleague of mine had a slightly different use-case, so I gave him the code and he showed interest in upstreaming it. After some probing, it turns out he decided he is not into the effort of upstreaming it. I can upstream the vectored WP once I write some tests. >> >> I am not sure what the best way to detect that a page is write-pinned >> reliably. My point was that if a change is already carried to >> write-protect mechanisms, then this issue should be considered. Because >> otherwise, many use-cases of uffd-wp would encounter implementation >> issues. >> >> I will not “kill” myself over it now, but I think it worth consideration. > > The current interface change is small and limited only to the extra -ENOMEM > retval with memory pressures (personally I don't really know how to trigger > this, as I never succeeded myself even with memory pressure..). What you > said does sound like a new area to explore, and I think it's fine to change > the interface again. Understood. Thanks and sorry again for the late response, Nadav
