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 9BD92C64EC7 for ; Tue, 14 Feb 2023 19:06:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3784C6B007D; Tue, 14 Feb 2023 14:06:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3282F6B0080; Tue, 14 Feb 2023 14:06:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A1846B0081; Tue, 14 Feb 2023 14:06:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0C18F6B007D for ; Tue, 14 Feb 2023 14:06:55 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DAF6D16022D for ; Tue, 14 Feb 2023 19:06:54 +0000 (UTC) X-FDA: 80466829548.18.3318EE0 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf16.hostedemail.com (Postfix) with ESMTP id F0AD5180015 for ; Tue, 14 Feb 2023 19:06:52 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kRXCfHvn; spf=pass (imf16.hostedemail.com: domain of shiyn.lin@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=shiyn.lin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676401613; 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=tR/3i49sq5hz9XtCZE+PWBTV406btHq8pkhmC0xJBgE=; b=0kRQO/nV3Amtp9pEWwkcU5yQmCwApjQN0j/YVcGLZw3Zsnw09z1MoLBSxOcT9wBzqLIhnT OXO5Vp4A/VaMZsstDbEnPFhZvscVmg0ooG0ADbb5KJEM/Wrb4B9cszJ6xTBj8ulG0PILC0 2owSlgWd58359WaTaI+vwZvxzedpxNQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kRXCfHvn; spf=pass (imf16.hostedemail.com: domain of shiyn.lin@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=shiyn.lin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676401613; a=rsa-sha256; cv=none; b=hGZ5rxz3G6h5WCMOmah8H3eLjUtJQOvA1CXWXVowws5F5KbpaN00lQFPX/cqg5T3dbrPH4 tP2USzlKiExFEpmGCvEln4Ezn7MhB7u0NMO0JzDt6nJ9ZczHQaq2qMYW1gYiDmWhWMA6Wp EfCshy5yiXJxR7gSlxk8H2mmJ5FD9Hk= Received: by mail-pg1-f180.google.com with SMTP id a23so10882604pga.13 for ; Tue, 14 Feb 2023 11:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tR/3i49sq5hz9XtCZE+PWBTV406btHq8pkhmC0xJBgE=; b=kRXCfHvnVjapwi015b0xlR827EdxddRsUAxsIADH90lYdHsP3qc5xUijELcU47v5DP RKhwxn/KRl3n6lCNAchGzTRGaXFTazeQUYYDaLbgg/4v9jjtNlV+eMiQEkHmKx/ELiMa eFJAbuQ2f2QTiy/inbPj6O3YLNor8m7xNX3yCXP8j5nvVi151z1mZTF5eZzazTvgpplt 2NlX6HDlCapdFRNgDhjHarJCwA0doM2TJJTXcytjM4zFHphszSKaFbrAJNP8xgmk1JLX aKncV6CBNTaSkfXSKXWx/HwNUD/7wIcUMIVjk3jYSkL57Y5VGcRZX00EZL/f3/vhRdHK baXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tR/3i49sq5hz9XtCZE+PWBTV406btHq8pkhmC0xJBgE=; b=8NllTzq1BOA1T7SSiErh/ndm3dx03G+27cREYCX4rLGWUeGKhtCHWO46m3nmr4l8i3 iNAAvg/k2rgSLrsOCQvkQpB8l5LAOcm9XH3IbrOiWbLJfYsy08y8YIOyUQWMkcoAuyUP i4y8Rw2rSQeUH+rlDlq3kVI3lv+uoUwKqwTQ5euxxGEccFOkmAIhO14yf2OYvDvHjabt 1ejIAzJFZfK9jrm5njzXVKVa56L3IVpFumOSkAW4710/0ydsa9XJYyoGuaok7p0YJA+I oA8k1vHGqt63G20QOONWt8d4z6QSLCR+6Fjcqa73QoGoDKVq3XfiH88oV1SViyKYAQrd hyrg== X-Gm-Message-State: AO0yUKVX9zS9dV/9v9kAOLSv0ab71FptbKCwvoWhqKxzcQNRp2dhek2j MER/G3zPqcLCCc1jzvnTQCs= X-Google-Smtp-Source: AK7set9KDqtSpLuf4DjmW649rLWZQ9WMurHdl9XlWBl5a0mpXl+jxH6VIQhqsW0P4nmezUIMvrdTSQ== X-Received: by 2002:a05:6a00:cf:b0:5a8:ac19:8f42 with SMTP id e15-20020a056a0000cf00b005a8ac198f42mr2623706pfj.14.1676401610866; Tue, 14 Feb 2023 11:06:50 -0800 (PST) Received: from strix-laptop (2001-b011-20e0-1465-11be-7287-d61f-f938.dynamic-ip6.hinet.net. [2001:b011:20e0:1465:11be:7287:d61f:f938]) by smtp.gmail.com with ESMTPSA id n19-20020a62e513000000b005a852450b14sm10172153pff.183.2023.02.14.11.06.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 11:06:50 -0800 (PST) Date: Wed, 15 Feb 2023 03:06:39 +0800 From: Chih-En Lin To: David Hildenbrand Cc: Pasha Tatashin , 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 Subject: Re: [PATCH v4 00/14] Introduce Copy-On-Write to Page Table Message-ID: References: <20230207035139.272707-1-shiyn.lin@gmail.com> <62c44d12-933d-ee66-ef50-467cd8d30a58@redhat.com> <28f1e75a-a1fc-a172-3628-83575e387f9a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28f1e75a-a1fc-a172-3628-83575e387f9a@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F0AD5180015 X-Stat-Signature: jwtpgfz3eujbppqzc3ge3b3ukdkdp9sj X-HE-Tag: 1676401612-329636 X-HE-Meta: U2FsdGVkX1+IdeKAArSoU7ZjG71p7h54AqQwmJIHJoecClaxdCdy2TgJ+ZmMk5DAu9I4k1JRmio6taGlNITkvhAebB+HPqfpV31+sJHfhrn5ryjDDRUfmzn6rBlE8Jib4eRcXhKLRCzDLErSnT/g2wnMSg/6dHas0180cGCepxcdlkgFvEdEJTvsTdxGkKiB6L2g/XK/cAAabuQ80P1HZevWoOBswon/wnjqtw8LoIgR2fp4ewBXuTo+7sx/w6f6Vqg9buRcoJ6bDCIrD5FB3lGw26ryvoG1qmQgwfkxQCCdA4YsEakyh8b96sn9ta9NwXw4MLSaRrj6V2NSt2HV3+ZhqPa1q7AuXiDwNMdGbZ9CqxxgMN29J4c+oiWndZ631P4Zo0sakz6wuhR9cRFlFyJ3Y1DVz/RHoC1IfmIMJwBAx5G0i4c9eievtED57sfKNfOReCX47SXO8TrA2rMRBQBGf/m9goz1KaRj8YfY0R3MbAZh6iKjPrcRiaSWeIr+4lxGSFF1ZGWghDEMTvzAkuBsttu+TsZ9kmByukIvGDrL5Gb/Y8TsUea9zmGqkfqGLAGjcMWGzUPMRCm5p7rrT2w9h3ui2qDEdgcLSpaTusVzfpQxGKAuaZu+/7H5K/qC+dnNtLC4oYqjb43n7PUpHRfL7D8ZZPgTEHPecUe1RWCSesIyKOWKMFeQlZyZS1XLx22guEMpTiBKINvHCNubD2mZnTnRWonOZrO8TMc75Lfz1lcimD1NKFTQuOSJGZffJ+OlixgfZ76QqWb48fvd2PL9yRgLDfRQk17YXGxcbXbea7KD7KfUa4iGRC8r/nkluWLqKKyw7tncEhe2TmYdZZiLY/kAB2WEHrooAUHnHBbjTmQUirPKZNEz8nulJkNcP8i1d3Zptft2pxQkDw94efMBRsJx0wQ3fawcKXLIBZ+5vrPVcPjkiOHhG8gXE+chGCL16+bo3kbGwv8Nsm8 WAXGNr9T 8tI9mNZZuN8vkUp5Qka3lrXmPvpiXYC19wIBjuqZP5lBsqyk9DJCsy3pPkbkZiYMNCRH5CBM8F08KZpE7rmtQ43LdRoGeN5ZAPFB9UKmKWYvvC2wpD+Vy6SdFw/PCWwNzu2MR96C1gILW7fqoLsHkM9vOOOL2Us/2xqoqc5OZPvhR36rgpeXT+Hn30kwebgfICPMjW7HemI+08GD7YGZO2UGGJEZZKhbxaoWbfgUXSfQ9wK+m0sflJpspTlJEZpuNy7QD9Yn6OkCCY/EE27w+86zMEmdj1kQ7tY/xPtyq+Xf6l5Ko0UnV2tUsXbRoTxSw0HiZcZIPblfBE0p0vptAT7Fgm07IToku6Mmt/pSptAPRef5f9U7xPSj38u2eyXWffktUsdKpqO7sSatOPTNGvnnCYWu4zS4CJEylmgddGQbLogrZhpYow7hB8mtiYd6Dy1FTXk9PhZPODCohj6gg3stjQsJBLznueCCX9bCr6cvSv+s5f1lcCjdVb0p2dbp9n4rUYfXGknmCygrdJP/w49Slkw== 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: On Tue, Feb 14, 2023 at 06:59:50PM +0100, David Hildenbrand wrote: > On 14.02.23 18:54, Chih-En Lin wrote: > > > > > > > > > (2) break_cow_pte() can fail, which means that we can fail some > > > > > operations (possibly silently halfway through) now. For example, > > > > > looking at your change_pte_range() change, I suspect it's wrong. > > > > > > > > Maybe I should add WARN_ON() and skip the failed COW PTE. > > > > > > One way or the other we'll have to handle it. WARN_ON() sounds wrong for > > > handling OOM situations (e.g., if only that cgroup is OOM). > > > > Or we should do the same thing like you mentioned: > > " > > For example, __split_huge_pmd() is currently not able to report a > > failure. I assume that we could sleep in there. And if we're not able to > > allocate any memory in there (with sleeping), maybe the process should > > be zapped either way by the OOM killer. > > " > > > > But instead of zapping the process, we just skip the failed COW PTE. > > I don't think the user will expect their process to be killed by > > changing the protection. > > The process is consuming more memory than it is capable of consuming. The > process most probably would have died earlier without the PTE optimization. > > But yeah, it all gets tricky ... > > > > > > > > > > > > (3) handle_cow_pte_fault() looks quite complicated and needs quite some > > > > > double-checking: we temporarily clear the PMD, to reset it > > > > > afterwards. I am not sure if that is correct. For example, what > > > > > stops another page fault stumbling over that pmd_none() and > > > > > allocating an empty page table? Maybe there are some locking details > > > > > missing or they are very subtle such that we better document them. I > > > > > recall that THP played quite some tricks to make such cases work ... > > > > > > > > I think that holding mmap_write_lock may be enough (I added > > > > mmap_assert_write_locked() in the fault function btw). But, I might > > > > be wrong. I will look at the THP stuff to see how they work. Thanks. > > > > > > > > > > Ehm, but page faults don't hold the mmap lock writable? And so are other > > > callers, like MADV_DONTNEED or MADV_FREE. > > > > > > handle_pte_fault()->handle_pte_fault()->mmap_assert_write_locked() should > > > bail out. > > > > > > Either I am missing something or you didn't test with lockdep enabled :) > > > > You're right. I thought I enabled the lockdep. > > And, why do I have the page fault will handle the mmap lock writable in my mind. > > The page fault holds the mmap lock readable instead of writable. > > ;-) > > > > I should check/test all the locks again. > > Thanks. > > Note that we have other ways of traversing page tables, especially, using > the rmap which does not hold the mmap lock. Not sure if there are similar > issues when suddenly finding no page table where there logically should be > one. Or when a page table gets replaced and modified, while rmap code still > walks the shared copy. Hm. It seems like I should take carefully for the page table entry in page fault with rmap. ;) While the rmap code walks the page table, it will hold the pt lock. So, maybe I should hold the old (shared) PTE table's lock in handle_cow_pte_fault() all the time. Thanks, Chih-En Lin