From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751225AbdEaOSY (ORCPT ); Wed, 31 May 2017 10:18:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33274 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751085AbdEaOSM (ORCPT ); Wed, 31 May 2017 10:18:12 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C94335D5E9 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=aarcange@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C94335D5E9 Date: Wed, 31 May 2017 16:18:09 +0200 From: Andrea Arcangeli To: Mike Rapoprt Cc: Michal Hocko , Vlastimil Babka , "Kirill A. Shutemov" , Andrew Morton , Arnd Bergmann , "Kirill A. Shutemov" , Pavel Emelyanov , linux-mm , lkml , Linux API Subject: Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE Message-ID: <20170531141809.GB302@redhat.com> References: <20170524111800.GD14733@dhcp22.suse.cz> <20170524142735.GF3063@rapoport-lnx> <20170530074408.GA7969@dhcp22.suse.cz> <20170530101921.GA25738@rapoport-lnx> <20170530103930.GB7969@dhcp22.suse.cz> <20170530140456.GA8412@redhat.com> <20170530143941.GK7969@dhcp22.suse.cz> <20170530154326.GB8412@redhat.com> <20170531120822.GL27783@dhcp22.suse.cz> <8FA5E4C2-D289-4AF5-AA09-6C199E58F9A5@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8FA5E4C2-D289-4AF5-AA09-6C199E58F9A5@linux.vnet.ibm.com> User-Agent: Mutt/1.8.2 (2017-04-18) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 31 May 2017 14:18:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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.