From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7091C05027 for ; Tue, 14 Feb 2023 16:31:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0532A6B0072; Tue, 14 Feb 2023 11:31:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F1DEE6B0074; Tue, 14 Feb 2023 11:31:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D97816B0075; Tue, 14 Feb 2023 11:31:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C48D96B0072 for ; Tue, 14 Feb 2023 11:31:05 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 986D7140EBC for ; Tue, 14 Feb 2023 16:31:05 +0000 (UTC) X-FDA: 80466436890.17.0337359 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by imf23.hostedemail.com (Postfix) with ESMTP id BD27314003E for ; Tue, 14 Feb 2023 16:31:03 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=lTQvvwCT; spf=pass (imf23.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676392263; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DeKrFVj5RLu1KKnNTVCusgp5T0P1wsNltnH7kGalgo8=; b=pV4IRf4kDXGs8Akd5MEO/8KicJKmeDiVoCgga5DB/8xP3+S2atCOUkmtbGdEms9q2P0/UL CVoHimrghTHhrqSbtBEv8N1ubLrESin/j1HW+dowC3bjdd8zOJejZjugMxxGY3W9GzV1VS 8kfE31ylvOEsnp/2Ii8zxc9MbcSzp48= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=lTQvvwCT; spf=pass (imf23.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676392263; a=rsa-sha256; cv=none; b=60Ixd1SVla0D694xr+TVucasSU3a5fOw3FrZTKb3BXVrOCFBVQd6mBkSSc2AwQqGSTjfH5 kQ0Cx1D/19YQysEuvvDNn9lagXvvh1uOvEM5queDFvteKahi0+C+cR+TODLD7haA7up2Jb OMkaNu/ZQStZY/mgeVISxNRppr5mRxI= Received: by mail-qk1-f176.google.com with SMTP id ow4so6352817qkn.1 for ; Tue, 14 Feb 2023 08:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DeKrFVj5RLu1KKnNTVCusgp5T0P1wsNltnH7kGalgo8=; b=lTQvvwCTQaIPkgC4gnl5/hjKykULn4Egld4GWcEFMZ5GSFB7wzUHzwatF1UsxgmIBf Q5L6KF6EAIjWy6lD9/0VT22Z4TtKiNNeST78ktjPDgN2LLePJQRvhVDC1juULo45oYs6 DIDhkOM/iYfIQtqcUytpx5/hzlrc62TtNADKfcal3v4gXHZ+K/Cl8YptRnp96r3ykb6m HQKKqnoOuaJSH/HMuxkIN4YG/ulb9k2pxtXZ4IzlKB6RX5/muq6WBdeQMNrSexeB2O8V bCXUt83hwneHXMKOuup0hNUYUA4Y9MUCprj61gZqjf3zltCdVO8ewwOuKRkwy0VkL7U+ +xEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DeKrFVj5RLu1KKnNTVCusgp5T0P1wsNltnH7kGalgo8=; b=18Jzn81ssCW5nOayy+3ms0w0LjWXgxI8m9K+bMqyYNh/T0tMi7rZL87XvM9OEOlZbs CBpjejn3FTFB0T7cvWevOkdcwEBksiEGAdYkaO7VpkzlZw+lUqxBulnhij+DurYmIR1P NwZ0Q4Db/wugSXdHF/KgLq31u99n+DFPEdGCuJ4X/hGljzzPjVgdbB9xqylz6lnNXO4h 2kugXnmtRPZHhE03wwekU3DJ1AmIJn9BYCF0h7Gm0O+ehOi6oe3jiWgF88eAv6QiBi/o qR7wTMw2CXgCIfbpqmshT7mBI0ZVKCYFuVqWMq/qY+IliRwjZ5Qbe6Cu1RlhbSSRxYTF x9Jg== X-Gm-Message-State: AO0yUKVsMtcEnnwDBVPFPLGXTywhwR6P6bbLjza1YT9yC3bz/I4Ni4Rv 7BkFGsPchf0UhQw8qPMNyCnzvMSrO7Nr3MWLOJX8/Q== X-Google-Smtp-Source: AK7set/L+qy5uWlxvBUp/FcipQgFAAkwrRaoGi3X/CTT2//GFz/QnqteBkgrL4rwfaRCkEkiLcVtj6hsQmZEOseBQR4= X-Received: by 2002:a05:620a:cc1:b0:720:6045:25ea with SMTP id b1-20020a05620a0cc100b00720604525eamr194899qkj.27.1676392262801; Tue, 14 Feb 2023 08:31:02 -0800 (PST) MIME-Version: 1.0 References: <20230207035139.272707-1-shiyn.lin@gmail.com> <62c44d12-933d-ee66-ef50-467cd8d30a58@redhat.com> In-Reply-To: From: Pasha Tatashin Date: Tue, 14 Feb 2023 11:30:26 -0500 Message-ID: Subject: Re: [PATCH v4 00/14] Introduce Copy-On-Write to Page Table To: Chih-En Lin Cc: David Hildenbrand , Andrew Morton , Qi Zheng , "Matthew Wilcox (Oracle)" , Christophe Leroy , John Hubbard , Nadav Amit , Barry Song , Steven Rostedt , Masami Hiramatsu , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Yang Shi , Peter Xu , Vlastimil Babka , "Zach O'Keefe" , Yun Zhou , Hugh Dickins , Suren Baghdasaryan , Yu Zhao , Juergen Gross , Tong Tiangen , Liu Shixin , Anshuman Khandual , Li kunyu , Minchan Kim , Miaohe Lin , Gautam Menghani , Catalin Marinas , Mark Brown , Will Deacon , Vincenzo Frascino , Thomas Gleixner , "Eric W. Biederman" , Andy Lutomirski , Sebastian Andrzej Siewior , "Liam R. Howlett" , Fenghua Yu , Andrei Vagin , Barret Rhoden , Michal Hocko , "Jason A. Donenfeld" , Alexey Gladkov , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dinglan Peng , Pedro Fonseca , Jim Huang , Huichun Feng Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BD27314003E X-Stat-Signature: 9m8czq65pz6h6hq4kiaj31isrhtmszd4 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1676392263-280635 X-HE-Meta: U2FsdGVkX19UGqvsZDeGt9hADbtH0PZtaoIz9KBWMni0umoxpNdzU10Rn6JRKoSc9N4C7GWcgYYmWfO3W3cdhJb97ECyFRq9LavbbvfxMWPObxBqsUaqA+rE4hBYkeRDHNeaBEeQ/CbiFAobxY/5dydch9Yu+thoyZtQHknT5FrAEAAK4yDwJqrU3mjIePDDTSmbaFnqYGzmZNQhz+FJ4RjAHfIPmqhNCnH6h3zlDcqxI+/1lRh6QjLcXNV62rRsDBSlnMk6b5w9vP1zvwCJaNq3l0TsR80yt6pS3si3DfiVaaMkcA1LJuTBygKjY7m4PvxOacrQjKpFjj/EmigrTN2bXRg4Dk5GKuCmKu5QJTQ5hnStUVaSJagW0rmnWBNc+GcGONXwDygIA0Atn2h7UtbDpwJTUajn20VINeD9UHZN68JATZhA0XcemKmrOUR28vuuKaY/xRjJMsDl1pzEd5CU2fp0g7HEGMtsAGaaei1A1qaB1WsZGSc0UXy1Ck46XVWKWXFhl5l8VVIB4HoWSF6CkH41siQwb03OXjGYCb9KbNKIED9PIhldX0+o/t6x1e1AW0glpbXxoiR2g2EfL51++s0164Y2QnVIkIIdJQqLD1JgwmOCGVOkoCXacZ1amBDVrvTz3rBRosbmqq+Elf4IZVg+XQC7Cqhw6LJotn4z+DvNXpfcMmC474OaHtUTt7lXHKl7LZDkRMMeEpeeL0Y552PG6DecHpchxntsJV6MIOQlKx/nbsEot1X+6Jfx/JStRi2lkbxWycZ4MJEk7D1+zYi5WLxNcYpFkfCm1JLEPT5uz25TatDtEcw5dp1CkWX4bWx766neU9HyOifWy2rkR0B58mhyClMTnpYLko+SP6VxF0iP92V9Wx3efCpjDJ4dYazW/+zEkdlY5TiGnlf1lIuUcqac+eg23Woow/h7t/U6L/IhzUQhXoyyP6NH1dAhmLK3R0bFZUjGFIM 5wsSZZYw mXsCIXBVQxULzAooqwS25qaSFfSErYl9SC+OGRPD03n/QpwjMbg3meWT1FhiawaxeMrd1R31GIc7R+jpBCQ20zKgRHiAlEa5Ddwh8dOd56oM52iG61k4Q8OSMyGZlr8h5Z74VTD25+fT7ruwyn18fNcnssPptAFHF5V25c9ycC/DMmvNgiNKkmSzLLO83TuEoVaak0/e9q43TciDk3FfLWzMyGbbXLqs8SMTf6U/qyLP05YVE48CBD4cSGyqF6WVloALPfMF5Jzq+75V5lBsH5Rj8qt1lG9uF43IX X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > > The thing with THP is, that during fork(), we always allocate a backup PTE > > table, to be able to PTE-map the THP whenever we have to. Otherwise we'd > > have to eventually fail some operations we don't want to fail -- similar to > > the case where break_cow_pte() could fail now due to -ENOMEM although we > > really don't want to fail (e.g., change_pte_range() ). > > > > I always considered that wasteful, because in many scenarios, we'll never > > ever split a THP and possibly waste memory. > > > > Optimizing that for THP (e.g., don't always allocate backup THP, have some > > global allocation backup pool for splits + refill when close-to-empty) might > > provide similar fork() improvements, both in speed and memory consumption > > when it comes to anonymous memory. > > When collapsing huge pages, do/can they reuse those PTEs for backup? > So, we don't have to allocate the PTE or maintain the pool. It might not work for all pages, as collapsing pages might have had holes in the user page table, and there were no PTE tables. Pasha