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 173A5C4332F for ; Wed, 16 Nov 2022 17:47:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 812F86B0072; Wed, 16 Nov 2022 12:47:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C3786B0073; Wed, 16 Nov 2022 12:47:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B1E56B0074; Wed, 16 Nov 2022 12:47:16 -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 5CB696B0072 for ; Wed, 16 Nov 2022 12:47:16 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0E3AC1A0683 for ; Wed, 16 Nov 2022 17:47:16 +0000 (UTC) X-FDA: 80140036872.14.3630888 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf23.hostedemail.com (Postfix) with ESMTP id 67B0714000A for ; Wed, 16 Nov 2022 17:47:15 +0000 (UTC) Received: by mail-vs1-f48.google.com with SMTP id t14so18680875vsr.9 for ; Wed, 16 Nov 2022 09:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; 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=eyCPyeJMcrVYxUOOMaoDJ2LNfvpxquoWrFx7efPrDZ8=; b=N7b62XhQzExJQ19iSSJdV9S1Sl+OMEc7fdQOBKMVt/0KOmv6HJZXkiOqukaKHgr+US EL6H/4lI7B/ZV3U+OkaunNG7bK/1YX2WVP1ep35JambbT2mPJC+54u5N6F5V7inevpSI /jtHd/t83esoNYpfH/yuF1F8IkFliNzivdUWc= 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=eyCPyeJMcrVYxUOOMaoDJ2LNfvpxquoWrFx7efPrDZ8=; b=78lo5guAk8tdY0QiqJXJ6sDkYqMrnKVp2keGAiFFG5N1ovqrswQ6ni1Ep9tK2pUfuE YqzR6VObRkary6urqj627raUZ8gF03hXIBnl5RckFOfqpdXaQf9RQIOZseP4QMfUXjx5 jQz4OJwiIVblCzzHjuvVe7knjvniXLAxP7u6Cd4OUr5mfvb0WONZTw9CNFCkSzxxfCcI jHHQq/dH+4zBEiVYp0aAMGz2Gre6yafvvNubcULEdN2b2ko6UhGoj5Sbqmx8H29n9RC0 fU8Oh++9ACGdiwMBkNks0oJBxUoZzFtyvm3JCYajwS746Uf5kwAfCyZs/JV5yxpwn7PD vazA== X-Gm-Message-State: ANoB5plmoOunMmxe82dYyU8IsiunicU6ltTRfZ9o9ACXp7ey+jKArKzQ ywYCUtTjv0KiV1TgUTm22j1se12tHLZCMw== X-Google-Smtp-Source: AA0mqf4u9RKEX+XmBA8O5g33r9bRtm4tKRhg0f89q3mHJx+4QocUqGHv6a3sendCobu/ZTvgdEeCqQ== X-Received: by 2002:a05:6214:2e4a:b0:4bb:a326:90c8 with SMTP id my10-20020a0562142e4a00b004bba32690c8mr21530964qvb.6.1668620407143; Wed, 16 Nov 2022 09:40:07 -0800 (PST) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com. [209.85.219.51]) by smtp.gmail.com with ESMTPSA id n77-20020a374050000000b006b5cc25535fsm10172989qka.99.2022.11.16.09.40.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Nov 2022 09:40:06 -0800 (PST) Received: by mail-qv1-f51.google.com with SMTP id lf15so12352706qvb.9 for ; Wed, 16 Nov 2022 09:40:06 -0800 (PST) X-Received: by 2002:ad4:4347:0:b0:4bb:a80f:3f43 with SMTP id q7-20020ad44347000000b004bba80f3f43mr21868972qvs.43.1668620405914; Wed, 16 Nov 2022 09:40:05 -0800 (PST) MIME-Version: 1.0 References: <20221109203051.1835763-1-torvalds@linux-foundation.org> <20221109203051.1835763-4-torvalds@linux-foundation.org> In-Reply-To: From: Linus Torvalds Date: Wed, 16 Nov 2022 09:39:49 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/4] mm: delay page_remove_rmap() until after the TLB has been flushed To: Alexander Gordeev Cc: Hugh Dickins , Johannes Weiner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Nadav Amit , Will Deacon , Aneesh Kumar , Nick Piggin , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Peter Zijlstra , Gerald Schaefer Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668620835; a=rsa-sha256; cv=none; b=gEyHiCPme/dLCioq0ePtUvJFM0Szl2aUjgljmpO3wzPf/VyL4Rgy8vv9Us6GyMqoZtXAkq y4wbSJD+GBiKyIIiOi/G6w5hJfs7yeU3bkgbkbfvMCLirQIWNq7QNCCkrcKx0BYNd45oAw mIpowYyqwu/Pj+mS08yZPIGd3Q+6Xxs= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=N7b62XhQ; spf=pass (imf23.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668620835; 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=eyCPyeJMcrVYxUOOMaoDJ2LNfvpxquoWrFx7efPrDZ8=; b=6/kCum0fWLZzwsiG4iDsBroI32pZSafl2jH0T2Lp/d9HHrOp+NRwWFGwCszamPRgdWxSko yoEFIKAiFfB5Olh14Okm+f79qvVtq19W1rVlCvBllzHas6LwE0qsSDw8yyiJ01dvqMJtP1 Y0/PG1ehS5opC/+hvIT3wMH4knhlKKY= X-Stat-Signature: hhp99kbwkshu96rt63iyfa4t1k3fnjhc X-Rspamd-Queue-Id: 67B0714000A Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=N7b62XhQ; spf=pass (imf23.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1668620835-510359 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, Nov 15, 2022 at 11:48 PM Alexander Gordeev wrote: > > Which actually brings a question whether CONFIG_MMU_GATHER_NO_GATHER > mode could be beneficial for UP? No, the NO_GATHER case wouldn't work for UP in general, because once we drop the page table lock, even on UP we end up possibly re-scheduling due to preemption (and even without actual kernel preemption, we have that explicit "cond_resched()" there). And if we schedule to another thread that shares the same VM, that other thread will continue to use the existing TLB entries. And if those TLB entries then point to pages that were already free'd... So the NO_GATHER case requires that you flush the TLB early even on UP, although the requirements are a _bit_ less strict than on SMP. And TLB flushes are not necessarily cheap, even on UP. Now, we could possibly optimize this to the point where it *would* be quite possible - instead of actually flushing the TLB, just set the bit to "flush on next thread switch". So I think the UP case *could* be made to be non-gathering. But I don't think anybody cares about - or tests - UP enough for it to make sense to worry about it. Linus