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 53129C4828F for ; Mon, 5 Feb 2024 02:14:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E3878D0001; Sun, 4 Feb 2024 21:14:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 993486B0075; Sun, 4 Feb 2024 21:14:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85BAA8D0001; Sun, 4 Feb 2024 21:14:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 781016B0074 for ; Sun, 4 Feb 2024 21:14:38 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 483D4A1920 for ; Mon, 5 Feb 2024 02:14:37 +0000 (UTC) X-FDA: 81756131394.17.E5CE76C Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf21.hostedemail.com (Postfix) with ESMTP id 475D71C000D for ; Mon, 5 Feb 2024 02:14:35 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=WoO7jeUK; spf=pass (imf21.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707099275; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tFyXg82UWmlPE+ig9jow6pwJAF00791AsGoKKK0IIVU=; b=vjIeb1c5QwLwx/mf/wCJqJBniTWuZgjiNyJ9bGboqXjcTla51AMNWoGE8iStkn7Mx2yb9K mAPyJIHPlex8quE0C5+1kLwk0LrzopqfQaqjpKTGE2WGEZnaVuUiAZ5Dilv1Qakz98G49/ 5h198HsB+T355renee/YMiOK8OOu+VY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=WoO7jeUK; spf=pass (imf21.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707099275; a=rsa-sha256; cv=none; b=DRu8Aqo1qt9j2uAXe6x++me1aH37MzZsSh101Ct2FeoTHsFH1t51DYg1mVBLkoRBqjSP1q qIzRGT42gVG1gm3hSHg5vWdW6e/XBaZ1mFV8VcWli3+ONJb0efwIpYaxwohqJYEEaqrBvu kT/gAgULC8xaqI2pDAsCfY6xHbGWV0M= Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-290c5c705d5so767886a91.0 for ; Sun, 04 Feb 2024 18:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1707099274; x=1707704074; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tFyXg82UWmlPE+ig9jow6pwJAF00791AsGoKKK0IIVU=; b=WoO7jeUKsjbqLoiFrHSnTMzaywZ4VXmpQJD0bfpIEOEOaX04/WKh49KDN7z/S62/ju uFLv4M5g6ug11gXZT5t8BcetA4ArE7EQcZMoSoM818wBTsggI4YYKX5uTcXNU6Hw366/ KEztPqCyElYkgLtgvlnLzLTnS9mVqwPx7j71punmbs7ru0BzLPlQ7PAL5mvPKk67H7O0 JAE7tZ4Ns7KTay2fuOvpR8AvmoKFE/Ekg0dVlAOYNbmvB7ndidnCGnqIVSmKgut0L7Wo KUDZf+0f3n1J9kpCmcMluJvNbFAYQG2ozf3OQuwBkiJE95u0WkLeZheVp6dCXCfk5CnY pa6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707099274; x=1707704074; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tFyXg82UWmlPE+ig9jow6pwJAF00791AsGoKKK0IIVU=; b=IuDaTLw35Y+OqGsveD/eMXe1HzX7bdLnCJRcTm8wPGNV8T2mwrNcTSvjvZE3FrhP+V uG+XOKkxAhOjZj9ql9x5TnUaaXZ58aeWO4uwLQmkhzOn6zGev1gJVSEbGwqKXfZuyy1+ wDUrkCZUf9vnLYiTKk5k9BjQ05m7sKJVKKrVrW9E+FzvZOuf/cGrntlYqfU47C49ZCrx EZzwug2XIwNeeo+xb6Rf5Wepvzq4tvC0du5qcsK228KeIqHifsGndOMEz7TWUv5AgDGd nVqiNHuYNUcKp7/0OOlOFGrGJnDK1IMdkUxBdxrSNfNum5J+0k3jx0OeTdjUe/M6YNAr MGnw== X-Gm-Message-State: AOJu0YyU2PrOiasOCr+Qelr3sagc8aboe1VXIrajXfojLA+FpZSxJmp9 SOtWTXdVaTFdExc9XDLrBnBaMZZC28cjMq7mEgQ+148ixVvN8xhKxY2CF16f13U= X-Google-Smtp-Source: AGHT+IEwQIC7jXtmYLSmgwxADVxy/6gqZeq63vbYZBJwSehUDq2LkFNeFIhCOM0IeNs5Pauzd+/fJA== X-Received: by 2002:a17:902:ee85:b0:1d8:f06a:9b6f with SMTP id a5-20020a170902ee8500b001d8f06a9b6fmr13589434pld.1.1707099273829; Sun, 04 Feb 2024 18:14:33 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXzaWXF1IGiLYQqU3QdZbMeWQAsPFYeTxr6WYf8piiX+Rb9cBUevGUYHNHanDzwgeBQAVOlflGkKjXDG1Qk9WzOYcCg8rxTD7t4AqTTUuvvvF5pPp3QE+heGBjMfpyObA62NSgQ63kf8omEk+qZAPuRwG+f2G8CtR9rq1vycChrW7KFlhIkQ0XqnBUC6wIQCaDNC09tMzQ3o6gfIWhpemvLBy7nvh69So3UtDe1jFBv6zH3Pxo= Received: from [10.255.134.6] ([139.177.225.228]) by smtp.gmail.com with ESMTPSA id j13-20020a170902c3cd00b001d9a422e0c0sm1602110plj.20.2024.02.04.18.14.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Feb 2024 18:14:33 -0800 (PST) Message-ID: Date: Mon, 5 Feb 2024 10:14:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] mm: pgtable: remove unnecessary split ptlock for kernel PMD page Content-Language: en-US To: Matthew Wilcox Cc: akpm@linux-foundation.org, arnd@arndb.de, muchun.song@linux.dev, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org References: <63f0b3d2f9124ae5076963fb5505bd36daba0393.1706774109.git.zhengqi.arch@bytedance.com> From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 475D71C000D X-Rspam-User: X-Stat-Signature: eqxy39817a8su9zmg65g4txbojtp6ugj X-Rspamd-Server: rspam01 X-HE-Tag: 1707099275-968947 X-HE-Meta: U2FsdGVkX1/A6w2+e4fqiy8awRVp9lbCOH4JQ7synPaORHvMB1AKzo9PVilnc6fBMlPOIw/WO7903V4JZOACG6X5V2QsTquhVM+PgpzsUoFpo19va0pib/s/VH/7S+LInC7haEdaJhKpb3XqVyXYCCKYVNiAUiar8Nl2RiCpfcp5ryyYHw9Acll3g3xcADzwwuCRkeWV4o7g1sUxq8+zICjLZAEloRg9LCuRNR9KbVKsvhGb2Xrp8nJha3/+fvzZH6f/aoC1+u1hvGg7DRPJHLVkaeJk0oaSdaWI+86hRNFzle0liNKd91rjOpWPIOS0j+SH98gYx575797+ZsA4csT0ppN/XdqffJDm5oBWpKkI+5NkA+q088V3ZVYfU4UAL3pIw08yr+dJrzFik6cFTCjOX1NFoHhKvMwQZQUvc/zVOb/kEUK5g1uR8M8HFqq8CrwrWdRb/ZinqFDYOUTMeKOQjHbSuZnthQQ4qME/turAOPNcDXDUxeiG0DDQPcc7pz3Aki6l3hzqBLX87I5IAlEdQdkzdhSW/lEZeGKn85j1G782FhZnEgPTtuzOQWlqz7u2c22MOQRLV/oaaka90cKu/PHEGmtHdjthHSieOrmKVbQXgVQtZzgKzMtMpr3QiFumsW7rSVYCKZDUXWydYZnKoZUGJ/aoTvp46hRWJm6yNJiuMqCyz6GRjrETPc6KGWS6gLZGs9Y8jNJlonCP9alRKhgI9GqKkxnmg6IvFAWEqQdhDrm5V8dH4ncT8O/0AIyERf1OqS+4dHO8eDMfcgBl/BNva34yuiUgZQ/Nw/6gUKm7HaXfJmvixL9i6veiPNZUt4HKPJ0Cpg4r8NrWsnYULsXVs4Ogp9tQH17/D+DW4VrioW43WphdSKOh6lEwRrq1AKXJwgYv6mYRSJj9TE088tOvom0a9tepN8aBtMlxf+OoJudoc3TU+OO11LWwCrgzfE9D7JblU70A+WJ Vll34MpR Dj5yBWLAzLghnKPe+WTgHUPNSNJMQSF5foj5Wxs6wXSWihDhoy04gZ/WrS7pDlEeZrVU+LEdgpQGglZl9USE6Kpo26tTLAUxyRRi+Tf13cqdojReGH/LEkgAI8/K/feH+kuwOSuh27ykbcE2jxP6ogqLLcJD9C6utN3vNklmT86J9TCgsbCtIpBmBQV7MRirCSkz5/QjaC6ZP73LgMPgDpwr5cxtzchuD9fuEK+VNKnr826Em6cfKltWvc05zhuYhskHxuB7+JW7yUviDXp0YDgR/pGsOeJzD5iSmrl8m7Y20Mg/fG43+ql3MjqNXbCyPX2DuyRmpYHaX7sLjUFiyrzmpCQ9ESbUAupvy+Yt0RD2gaztL/KIrQ1YELGySDMwTiB4YwqjBI8voTcr7iUL8VSoGGQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Matthew, On 2024/2/5 02:54, Matthew Wilcox wrote: > On Thu, Feb 01, 2024 at 04:05:41PM +0800, Qi Zheng wrote: >> For kernel PMD entry, we use init_mm.page_table_lock to protect it, so >> there is no need to allocate and initialize the split ptlock for kernel >> PMD page. > > I don't think this is a great idea. Maybe there's no need to initialise > it, but keeping things the same between kernel & user page tables is a > usually better. We don't normally allocate memory for the spinlock, > it's only in debugging scenarios like LOCKDEP. I would drop this unless > you have a really compelling argument to make. The reason I first noticed this is that we didn't allocate and initialize the ptlock in __pte_alloc_one_kernel(). So in at the PTE level, the implementation of kernel & user page tables is already different. Thanks.