On Tue 30-05-17 16:39:41, Michal Hocko wrote: > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: [...] > > About the proposed madvise, it just clear bits, but it doesn't change > > at all how those bits are computed in THP code. So I don't see it as > > convoluted. > > But we already have MADV_HUGEPAGE, MADV_NOHUGEPAGE and prctl to > enable/disable thp. Doesn't that sound little bit too much for a single > feature to you? And also I would argue that the prctl should be usable for this specific usecase. The man page says " Setting this flag provides a method for disabling transparent huge pages for jobs where the code cannot be modified " and that fits into the described case AFAIU. The thing that the current implementation doesn't work is a mere detail. I would even argue that it is non-intuitive if not buggy right away. Whoever calls this prctl later in the process life time will simply not stop THP from creating. So again, why cannot we fix that? There was some handwaving about potential overhead but has anybody actually measured that? -- Michal Hocko SUSE Labs -- 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>