Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751200AbdFCKkd convert rfc822-to-8bit (ORCPT ); Sat, 3 Jun 2017 06:40:33 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:45163 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751112AbdFCKkb (ORCPT ); Sat, 3 Jun 2017 06:40:31 -0400 Date: Sat, 03 Jun 2017 13:40:20 +0300 User-Agent: K-9 Mail for Android In-Reply-To: <20170602125059.66209870607085b84c257593@linux-foundation.org> References: <1496415802-30944-1-git-send-email-rppt@linux.vnet.ibm.com> <20170602125059.66209870607085b84c257593@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active To: Andrew Morton CC: Linux API , Michal Hocko , Vlastimil Babka , Andrea Arcangeli , Arnd Bergmann , "Kirill A. Shutemov" , Pavel Emelyanov , linux-mm , lkml , Michal Hocko From: Mike Rapoprt X-TM-AS-GCONF: 00 x-cbid: 17060310-0040-0000-0000-000003A0DAB8 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17060310-0041-0000-0000-000025973B0C Message-Id: <495443D6-654F-4751-8279-FBB96E3D90B3@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-03_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706030201 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2158 Lines: 63 On June 2, 2017 10:50:59 PM GMT+03:00, Andrew Morton wrote: >On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > wrote: > >> PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect >any >> existing mapping because it only updated mm->def_flags which is a >template >> for new mappings. The mappings created after >prctl(PR_SET_THP_DISABLE) have >> VM_NOHUGEPAGE flag set. This can be quite surprising for all those >> applications which do not do prctl(); fork() & exec() and want to >control >> their own THP behavior. >> >> Another usecase when the immediate semantic of the prctl might be >useful is >> a combination of pre- and post-copy migration of containers with >CRIU. In >> this case CRIU populates a part of a memory region with data that was >saved >> during the pre-copy stage. Afterwards, the region is registered with >> userfaultfd and CRIU expects to get page faults for the parts of the >region >> that were not yet populated. However, khugepaged collapses the pages >and >> the expected page faults do not occur. >> >> In more general case, the prctl(PR_SET_THP_DISABLE) could be used as >a >> temporary mechanism for enabling/disabling THP process wide. >> >> Implementation wise, a new MMF_DISABLE_THP flag is added. This flag >is >> tested when decision whether to use huge pages is taken either during >page >> fault of at the time of THP collapse. >> >> It should be noted, that the new implementation makes >PR_SET_THP_DISABLE >> master override to any per-VMA setting, which was not the case >previously. >> >> Fixes: a0715cc22601 ("mm, thp: add VM_INIT_DEF_MASK and >PRCTL_THP_DISABLE") > >"Fixes" is a bit strong. I'd say "alters". And significantly altering >the runtime behaviour of a three-year-old interface is rather a worry, >no? Well, there are people that consider current behavior as bug :) One can argue we alter the implementation​details and users should not rely on that... >Perhaps we should be adding new prctl modes to select this new >behaviour and leave the existing PR_SET_THP_DISABLE behaviour as-is? -- Sincerely yours, Mike.