On Wed, May 31, 2017 at 04:18:09PM +0200, Andrea Arcangeli wrote: > On Wed, May 31, 2017 at 03:39:22PM +0300, Mike Rapoport wrote: > > For the CRIU usecase, disabling THP for a while and re-enabling it > > back will do the trick, provided VMAs flags are not affected, like > > in the patch you've sent. Moreover, we may even get away with > > Are you going to check uname -r to know when the kABI changed in your > favor (so CRIU cannot ever work with enterprise backports unless you > expand the uname -r coverage), or how do you know the patch is > applied? CRIU does not rely on uname -r. We have code that checks what kernel features we can actually use. For instance, we use UFFDIO_API to see if we can do post-copy at all. > Optimistically assuming people is going to run new CRIU code only on > new kernels looks very risky, it would leads to silent random memory > corruption, so I doubt you can get away without a uname -r check. > > This is fairly simple change too, its main cons is that it adds a > branch to the page fault fast path, the old behavior of the prctl and > the new madvise were both zero cost. > > Still if the prctl is preferred despite the added branch, to avoid > uname -r clashes, to me it sounds better to add a new prctl ID and > keep the old one too. The old one could be implemented the same way as > the new one if you want to save a few bytes of .text. But the old one > should probably do a printk_once to print a deprecation warning so the > old ID with weaker (zero runtime cost) semantics can be removed later. > -- 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>
