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 6F307C76196 for ; Thu, 6 Apr 2023 14:40:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E76F96B0071; Thu, 6 Apr 2023 10:40:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E271C6B0074; Thu, 6 Apr 2023 10:40:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC7346B0075; Thu, 6 Apr 2023 10:40:01 -0400 (EDT) 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 BED636B0071 for ; Thu, 6 Apr 2023 10:40:01 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8E41F1C7178 for ; Thu, 6 Apr 2023 14:40:01 +0000 (UTC) X-FDA: 80651225802.26.AE3CCE5 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf02.hostedemail.com (Postfix) with ESMTP id 480148000C for ; Thu, 6 Apr 2023 14:39:58 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="rEIkwQ/w"; spf=none (imf02.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680791999; 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=xC9liSByLfpmJoqxob1Tfe5QJtboRITHVK7L2yzhpb4=; b=CBCjydoU+yCwNEnN1hk4fIZOdkEI/Zj//1DMKWCVBGuMUoC7VSiLC83Pbb1abXH4zr8Pko utDCwnShjVtgmUT/d0WlgFwRg4tbPJmXdqPyeLfMctROn8ecEKjBuyX9me+mzRnl0ssPsL qepLq+MBvEEZ0jHi/pLpRs2Cz4963rM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="rEIkwQ/w"; spf=none (imf02.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680791999; a=rsa-sha256; cv=none; b=XxXWxxqDYTo088LKfjgCAylAxk8N8X38An1SG6luk78FRAsVSxsCdt3c1ytgGvtxIgwN8Y iAROqMrERP8KvXFrGLZA9kD4cn+kYEJF73nE83qsr5ZHJFcIF32GRPmKoHwomxsn463Rqv duvZ8sNt4abBtwwdgua+1WawQmKn2f8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xC9liSByLfpmJoqxob1Tfe5QJtboRITHVK7L2yzhpb4=; b=rEIkwQ/wxL0jbUwKNMG+Rh2X7J fhszdLIzSoytlVtA4gcIUYPYI8IA1Jwh6TeTtXAh3APvzGn9QtZ/HqTywulvk4Df4PtnnO40IDaBd 4ZvtlOBF7yGAQPzpfFAmhO5IxmOLDaNwkkrydZ3Gcgl1WF0OUojR7tF3RXOQTtWC4wGL+7WVFfYZn ObQcLHeCK4J039oW17+VXorH+Ez+FqxveiV0q7ZKCMtFodu4+1u0q2K1HssdvPWS4UaLP12oUmZEZ MU7rPLjGwsEoA0GXCU3E/wk0EU3HtN/HGsZIZbNNtQKaCbLvxGCp5vLBqHYTa8Z/UolfGFRVEzFo1 yL+DHjGA==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1pkQlu-00AY5v-2L; Thu, 06 Apr 2023 14:39:30 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 9BA2F300338; Thu, 6 Apr 2023 16:39:26 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 7FDF3212E36AE; Thu, 6 Apr 2023 16:39:26 +0200 (CEST) Date: Thu, 6 Apr 2023 16:39:26 +0200 From: Peter Zijlstra To: Valentin Schneider Cc: Frederic Weisbecker , Yair Podemsky , linux@armlinux.org.uk, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, will@kernel.org, aneesh.kumar@linux.ibm.com, akpm@linux-foundation.org, arnd@arndb.de, keescook@chromium.org, paulmck@kernel.org, jpoimboe@kernel.org, samitolvanen@google.com, ardb@kernel.org, juerg.haefliger@canonical.com, rmk+kernel@armlinux.org.uk, geert+renesas@glider.be, tony@atomide.com, linus.walleij@linaro.org, sebastian.reichel@collabora.com, nick.hawkins@hpe.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, mtosatti@redhat.com, dhildenb@redhat.com, alougovs@redhat.com Subject: Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode Message-ID: <20230406143926.GP386572@hirez.programming.kicks-ass.net> References: <20230404134224.137038-1-ypodemsk@redhat.com> <20230404134224.137038-4-ypodemsk@redhat.com> <20230405114148.GA351571@hirez.programming.kicks-ass.net> <20230406133805.GO386572@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 480148000C X-Stat-Signature: 5jr1q1rzifhbubtgnf9gbjcenbcut6sa X-Rspam-User: X-HE-Tag: 1680791998-277823 X-HE-Meta: U2FsdGVkX1/QyUINDX3LKct7rt/jFniyg/lIUf5LGWIoDaG1j5vOMnthcjrL41vGj1meMCy5nQZ2NpQfzRRtWTWXbxC2Mk5tmIvQME/e7HRwXO0tnYvm37d3VQmRa5CgGt6UfCVLOM+JhMg8jFKKhhV+LStG0UbhD8QknlUpHGQBKbfeNCapgHoEl10wSfwsg60+Tdm/8g9gwrSdbjAizPRBiSzsqLk/Mbh5DUrKhinwPe5HCT2wNjItw6mb9ysUVB3n/yJVmL0OQsfPZKYZM1qzuTTGTIE+Ik7UUOBKRQPWqgRojyZy+PDJK7sskerKBbkYvXBlRyPj31YRXZUT1LJqsDHk0ojOMioxsQFgn47Kvcys93nLm74ZUuoHGmjuynpqse244XnXKobaJDmJ9UqBoe2sW1qBIrNStKYlrgXSUxKDFascO7g/cZadJhrKjR/b2TG7+k5qxb328xo/zrStcld2FQp+wIMVwv28J1EssuhRAgPXGMpxoSZ+ZcksKESzygiDSVtlfc1QyucLpqukPDCO6TM0mqFhu/+ni9YBEyWy1TVpdd+rAEmP84O8KLzJTHmS082DnTj4H9hQ9H93XLdE97icMKLiOkoE4cfqfF5a+SLJIMVeBvg8yphV3is7rmWqCGf3M1KiVoGZ1RBmjLd4bXLNEkuj424tuEiTrA2VmKNUXzapDdw8Bw5v6tTHQlPpVCcd9MqVZ1GQcuf3gSBOZd8dk+ORrHjyssjS9Lcjc7QjxRh5Z2lIjPCcQyp7DhaC632fBcRgDVVCd6RFXuHIHeNihWPZnygCvf91e2YL6nMq47SdJzuJ4Zr5xTNuA2g5EIGK2jXs99C5S7EWpfiPu7KQhB5lJ8Kir17z1a6TLRMu5gXba0MHmBl/uncfGAFpCph6AWvOsiDCd3ja0EVLSfvZYJf3iPNKEgEt7zHvpyLoNcX1T+nmcwWNwby2i1RjOCFT2CPY5u8 YY4dH7Vo Dv8ZvlPw4gXyZJ+BtHGo7AvwVKtyaJct/4RMD1+CppcEo3n8HlUaz1uNhnmav240OEBdZtXl7RrdQeHzl6tHRS4Z/5nB+u9ydtZuuma/u18+oMYcV8QQormN+JFvmG/4N3WY0oB/XOF/+lP+0djahrkLcpYqI1mpH0xZ/SXKRDotg2zHY6L/2IbK4SnKPYPRllWrlxl89jCBdG2fZerAbRQFWE0p8VWx2Ulz0LA7u4T6EsjHcUOLbA03tZZZ98McsSl4B8b8drbH3+vsQxmwuAj08gIrN66nBjEo+ 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 Thu, Apr 06, 2023 at 03:11:52PM +0100, Valentin Schneider wrote: > On 06/04/23 15:38, Peter Zijlstra wrote: > > On Wed, Apr 05, 2023 at 01:45:02PM +0100, Valentin Schneider wrote: > >> > >> I've been hacking on something like this (CSD deferral for NOHZ-full), > >> and unfortunately this uses the CPU-local cfd_data storage thing, which > >> means any further smp_call_function() from the same CPU to the same > >> destination will spin on csd_lock_wait(), waiting for the target CPU to > >> come out of userspace and flush the queue - and we've just spent extra > >> effort into *not* disturbing it, so that'll take a while :( > > > > I'm not sure I buy into deferring stuff.. a NOHZ_FULL cpu might 'never' > > come back. Queueing data just in case it does seems wasteful. > > Putting those callbacks straight into the bin would make my life much > easier! Well, it's either they get inhibited at the source like the parent patch does, or they go through. I really don't see a sane middle way here. > Unfortunately, even if they really should, I don't believe all of the > things being crammed onto NOHZ_FULL CPUs have the same definition of > 'never' as we do :/ That's not entirely the point, the point is that there are proper NOHZ_FULL users that won't return to the kernel until the machine shuts down. Buffering stuff for them is more or less a direct memory leak.