Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a7ccd8b2-c659-44c9-cb18-1496f99aa5a8@oracle.com>
Date:   Wed, 18 May 2022 15:36:30 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To:     "linux-mm@kvack.org" <linux-mm@kvack.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Cc:     Michal Hocko <mhocko@suse.com>, Oscar Salvador <osalvador@suse.de>,
        David Hildenbrand <david@redhat.com>,
        Naoya Horiguchi <naoya.horiguchi@linux.dev>,
        Hugh Dickins <hughd@google.com>, Peter Xu <peterx@redhat.com>
From:   Mike Kravetz <mike.kravetz@oracle.com>
Subject: vma_needs_copy always true for VM_HUGETLB ?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WGVhRkJtbm94WlVPbzhoYVV2RXg3NXUrTmZwYTg3TmlhbkdtOTNiZ3lPVFNL?=
 =?utf-8?B?dTJpMFE3RVlTbjljcTF0cHRaeVMvbW0xTjBuUEtlM2dmLzNGUGRrNUEzV0x2?=
 =?utf-8?B?TGdjZXYzbVlSTUJHT1ZLUTVHUHZ4R1l1djRpMjhwbEZpM2FCSysxR0ZTQ0or?=
 =?utf-8?B?MzA0U0lUeUc4NXorSDdBbTM5eTF2UzRsNGFZdlp3MXo0UnRBeUxlSTltRUNZ?=
 =?utf-8?B?TUhEOGtxa0Iwd1l6L00yRzhOQ0kxUXEvbnNQOGFOVDIwNVdOOGRWY1VKYmxP?=
 =?utf-8?B?OHFub09iRUdRMURFeDRPdjcwdUxvWDBYTS91alZOcDdobTVOdGtVVmlVRDdU?=
 =?utf-8?B?L3BhR0p2YkFDQTIrMjRncXJoazVWN0ZFK3ZIMVVONktUNE5rU1dTYjVuWXZi?=
 =?utf-8?B?eUZOQWVpSEE3Z1JNOS9aUmIzOHhSSWx2MTNDVHl3SnQxN0VqQXNHSWZnVEFI?=
 =?utf-8?B?K0Z4KytlNC9CMjRPRlVhU2F2UVFKTUU0blhaZEhZaWNPc0l1TjlqU291L01q?=
 =?utf-8?B?OFhselhqc3RlM0dld3lacGtDMW13QXNzWjR2QjliVm9JVVNwSXBlbVBKWVlZ?=
 =?utf-8?B?QnNXdVJLV0wvSWNZN01TaEs4MXcvWWM3VnYwK3czcUFlODRMKzBUcHROZWhz?=
 =?utf-8?B?eEQ2Unh5Zi9KcTBqVE9mRlVMTFp1bjQzQlhGV2g4UXNjU2JxTjhiMkw2dXZZ?=
 =?utf-8?B?ZERGMWxiTE54dk5WSFo2ajNpTG5XVGpXd1BhWk1RellmK1VVNFhSdEVMK0Mw?=
 =?utf-8?B?YjljQ1A0MmVDTElrc0dIV1lOU0lYdk0vdmNvcmZQRVQzNlN2SHd4N2UvbjFV?=
 =?utf-8?B?dExnV1Y4bFlDVFYxV1FHMFlHajgveEFqak00YlpjSXNqOE5Mdlh4VlJiWGRx?=
 =?utf-8?B?QlpaMXUrYlU4cWd5NEhxeG0rOG54Z3F0eUdGUUFnTFY3Uy9CRVBXb2sreGFj?=
 =?utf-8?B?eHpSOEMxUUxzU3ZoVkhxajlWRTZkWjBuQ0NpTmxDbkFrTkhLWEk2UXczNG1t?=
 =?utf-8?B?VGlhQTlZSGhkSVA5K3k0cXBSVGxhQ3ZjRVVnWmkwMkhJQkdKTXE3ZTZLeTRt?=
 =?utf-8?B?a3I3bE5ONXFZcGxSTVR2OHZmZW02alVBUy9BNFNaMitBbEtXbGNLblFqV2R0?=
 =?utf-8?B?MG54RVhreUNQdDhKaURuY1lDYW1Namh3a21TUVhxK2psOE9hZVNlaW9wZnl0?=
 =?utf-8?B?N2pTb3dGcXBaM1NMV2ZYL09UbFA3WVgrS3dKeVlLY3ZPSkw1WlpFNmxrc2FB?=
 =?utf-8?B?Z1R6S253dTFGRC9oNkpHeWlvK3Y1bWI5SitpeHBsVFpiQ3BHYUI1TC8yREx1?=
 =?utf-8?B?c2hUTk5hVXBGWldnZjQvTS94a1hjRCt5TjJvZVJUWFZDQzJQd2J2WVBKaXBM?=
 =?utf-8?B?dmJ1WW9rYmN3QUU1TVJpNVdYNG5xZm9DU1kvRkwrM0R6QkFTc2QxeDFvV1lF?=
 =?utf-8?B?NUZtOTlYM1pIMEgyZEh0UkFhc0RTYU40Y1ZHeC9FdEZwVzZUM21wR2s4OUE3?=
 =?utf-8?B?QkUrME55RUlHL25pT25JbjdDQlFrM3crSGpnMVFEcVV4ZWp0TzdidytDSG43?=
 =?utf-8?B?WHhmUjNxZWFXTHBtUlN2empGeVVGUUhxcjhjRVl4bC9nVllYM2R1M015K1dZ?=
 =?utf-8?B?YnZZTGVxS3NZNys4dXZnRlpqTVVCRnlDL1JUTjNzMURXNGNZbTIzUHVLVWI2?=
 =?utf-8?B?bzI0VnNzUUhEZjhmZVduNkNSTGJEejFrMkZFRENrcTM2d2Y0RHhlMkZkbWQy?=
 =?utf-8?B?VXpaSVFacTRJMWQ5Q0YvbTNQcEg4NHQ4RmN0dUF5MXE5QnBEK1R2T0t5WWVu?=
 =?utf-8?B?UzgrVTY3SmwwcGE0UG1BbWxnZFVYKzNFTzFtKzNvZ2haV050R3ppZ21VcWc0?=
 =?utf-8?B?NUZBcGRZb3l4RmNaOVMyeXgvb1lLbExqTlEwZnBRTEdtMDFUWDhQWlh5TnJp?=
 =?utf-8?B?UCtTUnVrL1dEWmJ4dkFDdXJsL3pDZHhYVk1vaUZOZlBZVkc3dWNBVS8zMEFo?=
 =?utf-8?B?dUVCTUFjNGNJWlFrS0NHalFpQ2ZFdzlyM3p4R2xnczZlVXpkdlZPMGlIYy92?=
 =?utf-8?B?Yi9DeGN5ajcxUjZBQjZXMTV6bVQvdUF1WUZKajdqdlZzOXBzNndHcWhmV3R2?=
 =?utf-8?B?TXdoS3RCQ1dHZlBFUGVIOFZtdnhvaEFOT1hqQWlrTm5CUlZKbWVrZFc5RGZE?=
 =?utf-8?B?MjI5MGJ3bGxsT21KSXZnejA3a01XbTkwUnZ0RTZEa2Foa3d0cjdKcm1iUW1M?=
 =?utf-8?B?RGEzZnNUZHRRN25ZSmhEWld0cEJGMldXdE1ZTnpTZTl5cHVJaTFJSXo3VVZz?=
 =?utf-8?B?OUwreWhqWjBqb2VKQWM1RmhyemZLTUlJcS94R1Bud0o4Tm1COE1GVXhVTzMv?=
 =?utf-8?Q?LMgWr1nQBfaaWfvY=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f9aa33d4-c252-4c5c-1b45-08da391edb27
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2022 22:36:31.8201
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hLR1Z3ezXD3ASuMg3HIpe8rC2GWqMye7VIry7cxN1WXQamW6tZ2Ab7E52OUdqWv7PECW2NSn2uPHMqiEiXlKDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1823
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874
 definitions=2022-05-18_06:2022-05-17,2022-05-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 mlxscore=0
 phishscore=0 suspectscore=0 mlxlogscore=788 adultscore=0 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2205180125
X-Proofpoint-GUID: _kSt_ubcV7zV11TrvxQ_GibHO2t7ycnk
X-Proofpoint-ORIG-GUID: _kSt_ubcV7zV11TrvxQ_GibHO2t7ycnk
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

For most non-anonymous vmas, we do not copy page tables at fork time, but
rather lazily populate the tables after fork via faults.  The routine
vma_needs_copy() is used to make this decision. For VM_HUGETLB vmas, it always
returns true.

Anyone know/remember why?  The code was added more than 15 years ago and
my search for why hugetlb vmas were excluded came up empty.

I do not see a reason why VM_HUGETLB is in this list.  Initial testing did
not reveal any problems when I removed the VM_HUGETLB check.

FYI - I am looking at the performance of fork and exec (unmap) of processes
with very large hugetlb mappings.  Skipping the copy at fork time would
certainly speed things up.  Of course, there could some users who would
notice if hugetlb page tables are not copied at fork time.  However, this
is the behavior for 'normal' mappings.  I am inclined to make hugetlb be
'more normal'.
-- 
Mike Kravetz