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 EDA4DC25B48 for ; Thu, 26 Oct 2023 12:48:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 706646B036F; Thu, 26 Oct 2023 08:48:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 668BE6B0371; Thu, 26 Oct 2023 08:48:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5099A6B0372; Thu, 26 Oct 2023 08:48:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 409036B036F for ; Thu, 26 Oct 2023 08:48:20 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1AAA5C0610 for ; Thu, 26 Oct 2023 12:48:20 +0000 (UTC) X-FDA: 81387590760.11.61102C2 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf13.hostedemail.com (Postfix) with ESMTP id 10D1020014 for ; Thu, 26 Oct 2023 12:48:16 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of "SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698324497; 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; bh=+dW03GHWYPLZLaKTxAjZPxWe4sfH+uCdwkxvOYuNrWc=; b=RMm63w1OectsNiZKg5TlY2AmV4JzIiS0U19aTa4Biri5ZMuw3cPDqOJcNkkYj25boAjKLF IQaSCSXB2DjPTSaLFW0YhMpRInDfFSn2RWc4Wb16/xgbmNvjMdy46P7S/c8FrQWSr7WUdi 1SYvq9zu4NPtGQ3hePtrci2eTx/vexE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of "SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698324497; a=rsa-sha256; cv=none; b=uSOYYBYx/1wcjMWn8Wgy8npYIy03+jNwa/w17rnxk4Nwy8ADufOAEoiHnh//17+n6ASK+I BOCFm7epE1UVIk4DP15BCVWe0srk8rFNxHQy1i3nRsDsqF4cw5coaG/3LxHRBYPJZ8Tn2h hIkZMU5g/9u5HVWIyzMBM6yNJzg4Mq4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 987B2CE3F12; Thu, 26 Oct 2023 12:48:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBF58C433C8; Thu, 26 Oct 2023 12:48:08 +0000 (UTC) Date: Thu, 26 Oct 2023 08:48:07 -0400 From: Steven Rostedt To: Sergey Senozhatsky Cc: Thomas Gleixner , Peter Zijlstra , Ankur Arora , Linus Torvalds , linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Youssef Esmat , Vineeth Pillai , Suleiman Souhlal Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED Message-ID: <20231026084807.3d50aee9@gandalf.local.home> In-Reply-To: <20231026075016.GC15694@google.com> References: <87edj64rj1.fsf@oracle.com> <87zg1u1h5t.fsf@oracle.com> <20230911150410.GC9098@noisy.programming.kicks-ass.net> <87h6o01w1a.fsf@oracle.com> <20230912082606.GB35261@noisy.programming.kicks-ass.net> <87cyyfxd4k.ffs@tglx> <20231024103426.4074d319@gandalf.local.home> <20231026075016.GC15694@google.com> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 10D1020014 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: g76whmtkzpn8bhxmxipyfhue7ksktxb3 X-HE-Tag: 1698324496-856312 X-HE-Meta: U2FsdGVkX182s4llQ+z8oCG4yK21nGSHcB9k9+mW+ZM+ptz9qy5SjYeljyY5X4OvFkjeTKVfvi8h9JIGtFXPiX8w6saSO2a+KUZfC2XHhmNxbIwjw22SYuvX3rZ9C/+SR04srENS7i+jyYMkx4wuBkl2EImTXwOTPrHgrWeQ5a/CeCKsX/GDaYenfzzY+1CWAxbrEYl5yJA+vPpgDe++Wq4Lm6kP8KP3o0CuLAHupjpp/TtGpHhSW0nRikLqzUX7imI9wTEzPjotm53LKhFjCozHPJAqlSAXQK46M+/HIOF9aQYxnciDe67G5S8VenJiXQPVTUqxW5BEAkclr3H6w7rBefyNt7m7l4guZL0PJOuRSMP8z9tC6fDCW1cUoQ6AYv4sDscLc3zxfnM1f9nH3ySOI37Xy2SpWPj521JK/TkZ8nzJ6iUh0iDuO50rBZeAHnz1Q+cL3znpHIR8zg20lkRjETNYHb3QnhNMaJMG3DDkg/UC3EI4DbQnijkgppXJFT4l5jLwvy/JOPpTlGnCkTFsz7dofyIAxrjAEU0zksB5d8L81U+5ES/BihRRF4JZQaqSKsfnfpsP/KTI+WJG3GvQsBHWOcge6Cw1Y6hvWFjL3CIRe5yVHZ2by5Ft/XXVz9kRCR8+x2PjfqvhCGY0WvyVBgKybCbrSJw4JJaA0fIX7b4LpEGxpFRVP1HJI/pvShNZfB0jWy5FdreEPnUEHTxWGgC+J8OR7XslbkkxV9WxwW6SYTrU/I+Gd5Tj7yL4kbXgmrx+bEbsEXSgI2Slkk+431I15uUyX9+LsH/VCKrTFWS3X/lWVHhjMcCzpagAP7hU04QRzhB7NRO2TE7wZfuxC9S1lOT5mYjxhp3sgeBEHxVcl/8g9mrDzw7bda43MS8CbJVQpeVaeRBthADQBMbYxtNP6LMoEcEuPDw6SErZzfI7LUyt7ZenuMUUbl3CQdxUfn7ea7RmMHCEA/P evQVh0Ms Tg826X8TZaK2GpWzI7HJzd6A8Ol59dRh0CLscUKS0SG3qEPqVe6rEtA8d128Nn+0u0xp/+cNJVHoBdQDRDtYL/dy/BQ9iYbMtQAgHwl9txpc8z2nBxsV+n8FDTpsEeU1YTQUAVqEeMYUwpR5Hc419ieo3hpF739ABNuVoHBk7+JcNnONAqZCQppQBSNnYeWCy+dgEvZJSGKsdmvn68rvgug63TLURdvQveqDVp8Qmj7A455GMtxoImr066dzfdYRjaU2wxhhR7o/Kj9KdUPwFo9xypwgiwYHrlBAe0HqDqFvrvhEhpTi4Vuya6IcDSghJM5RpLs3FYTMYD76Ur8yHGi819isDnOEQ1oPUeu1vvCKwJxCgkoan+fzKrH4hWY9tdWxz 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: List-Subscribe: List-Unsubscribe: On Thu, 26 Oct 2023 16:50:16 +0900 Sergey Senozhatsky wrote: > > The goal is to prevent a thread / vCPU being preempted while holding a lock > > or resource that other threads / vCPUs will want. That is, prevent > > contention, as that's usually the biggest issue with performance in user > > space and VMs. > > I think some time ago we tried to check guest's preempt count on each vm-exit > and we'd vm-enter if guest exited from a critical section (those that bump > preempt count) so that it can hopefully finish whatever is was going to > do and vmexit again. We didn't look into covering guest's RCU read-side > critical sections. > > Can you educate me, is your PoC significantly different from guest preempt > count check? No, it's probably very similar. Just the mechanism to allow it to run longer may be different. -- Steve