On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > I'm not sure if it should be considered a bug, the prctl is intended > to use normally by wrappers so it looks optimal as implemented this > way: affecting future vmas only, which will all be created after > execve executed by the wrapper. > > What's the point of messing with the prctl so it mangles over the > wrapper process own vmas before exec? Messing with those vmas is pure > wasted CPUs for the wrapper use case which is what the prctl was > created for. > > Furthermore there would be the risk a program that uses the prctl not > as a wrapper and then calls the prctl to clear VM_NOHUGEPAGE from > def_flags assuming the current kABI. The program could assume those > vmas that were instantiated before disabling the prctl are still with > VM_NOHUGEPAGE set (they would not after the change you propose). > > Adding a scan of all vmas to PR_SET_THP_DISABLE to clear VM_NOHUGEPAGE > on existing vmas looks more complex too and less finegrined so > probably more complex for userland to manage I would expect the prctl wouldn't iterate all vma's, nor would it modify def_flags anymore. It would just set a flag somewhere in mm struct that would be considered in addition to the per-vma flags when deciding whether to use THP. We could consider whether MADV_HUGEPAGE should be able to override the prctl or not. > but ignoring all above > considerations it would be a functional alternative for CRIU's > needs. However if you didn't like the complexity of the new madvise > which is functionally a one-liner equivalent to MADV_NORMAL, I > wouldn't expect you to prefer to make the prctl even more complex with > a loop over all vmas that despite being fairly simple it'll still be > more than a trivial one liner. > > Thanks, > Andrea > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> > -- 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
