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 555A6C77B75 for ; Wed, 17 May 2023 16:32:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0DC7900005; Wed, 17 May 2023 12:32:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBDA2900003; Wed, 17 May 2023 12:32:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A866F900005; Wed, 17 May 2023 12:32:31 -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 96006900003 for ; Wed, 17 May 2023 12:32:31 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4AE2A40657 for ; Wed, 17 May 2023 16:32:31 +0000 (UTC) X-FDA: 80800290102.13.D842917 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf04.hostedemail.com (Postfix) with ESMTP id 3065540002 for ; Wed, 17 May 2023 16:32:27 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hUM1xSxF; dkim=pass header.d=linutronix.de header.s=2020e header.b=rFpkV6qE; spf=pass (imf04.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684341148; 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=Ke+G/iI40gnNEDdAG0OW/5zcPgY6+ZrnjbLluwvcZsA=; b=1RDVKXjmHY3deGdBpz9aGn4ERrOhl5mRc24VzKvfptiNYoGUhq+Gw6mcFBs69omJGkBN2H s3483W4uLMvt8hS693ihck5A/ZPng8fc6TyDYSdEg9wTityQfrqwYYi2Q0nde/nHZ98nAM 6lo5sj35zONLUNyrI1mjrRCeddiOu7k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684341148; a=rsa-sha256; cv=none; b=sx8QfYDRhxyRTalIZ1mkdV5YF2p2FBmfm7HG5x8qPAhlUH8boRATxphIctbyFUb3hYrYZQ wL58FBK2PfxR+6QaQcmRngptH0DBN0jp+xKXs94RICIdbjGc5nlLJcUlTz2AtKPgHTjszP ZwJt8fEFydSaUrjxAnH216ALeaOJdaQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hUM1xSxF; dkim=pass header.d=linutronix.de header.s=2020e header.b=rFpkV6qE; spf=pass (imf04.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684341145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ke+G/iI40gnNEDdAG0OW/5zcPgY6+ZrnjbLluwvcZsA=; b=hUM1xSxFMjFfQwiuTqEN6MbgsqsbQ6cmrmqQ98zdFeAaVblQ/MiP1u44JzeMVr+/m4QP9F Jt3Nr1NiQrWtYbOR0TuueNmd2/CK0WWr34/qGdDO4sUDw0tTEo7YAlrFHvKEaUH8FPUedZ bfLoZpMXfbCUfKk6RzjkRScjuBSeSX2mpe96YzaIKT6amHqqgRzULvdKeHda1q9u5ukakt +CZpZN/MTqXjTdd4bfucSDZiic+m0azrHawkPRHqfyS4wZRUxj3SM+KvopvWMjv1pD96A3 3/riWZGYY7sAdU4QEl2QHotJvgz4/8I8nOjLesdiG1P20FKxt7mAg0Q+azClTA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684341145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ke+G/iI40gnNEDdAG0OW/5zcPgY6+ZrnjbLluwvcZsA=; b=rFpkV6qEaXKjGNcL2ZHGHwMPhGeniaxTMcXXzWNRUCH9/rGnuHlwVf9BLo25IAbuUHewc+ ZO9E2unVkfB0VFAw== To: Uladzislau Rezki Cc: Uladzislau Rezki , "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges In-Reply-To: References: <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> <87leho6wd9.ffs@tglx> <87o7mj5fuz.ffs@tglx> Date: Wed, 17 May 2023 18:32:25 +0200 Message-ID: <87edne6hra.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 3065540002 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: tigc3wpkh8ge449u9zbix6dt6hkey774 X-HE-Tag: 1684341147-602741 X-HE-Meta: U2FsdGVkX1/628K5Il3owkCcn2RxCnWwd4xW74lBCKZhk2I3yd8gOrGWcQCIv87J+Qs9bsG2klq4yxJ+LgVK7vfrOJb7LPllj7gHb/7qgglRfGNlRcOujQNftgj7zQriKHjfpv+jXdGrFpHOo+BaQzrTv57VWKOjm20AQG0AiNAZJx638zqSB6N0RyjQmmIdlGZ9AnAQldtABnvjBe7E2pAzxCndj+lp9PcfMzTGb9bFZYprkBDVjFEiuQqFksq3Dx+s1yVPIqkD8LgTpipP3R8T7lSizgZ6Lk2B3xS87s9k0bPLsYcYpg2Vz9qpyfJhNUz7r7zwv4oaRwJfHVWpq0tv7W5qfucaI2WYIYEnYWR1AlsMMtpqsneu03zwA6/+FE+jP9v+42AYWjjeEfWbXLcIjnlzC80N4yFxC7OweerZ/R0WsiylsPS2Ai5+yL1mIbIIaau61z3LELDIMutIZYi3Xm657RDlbnAVaPjR+9mU7Ls/o993NvPPDtxher3ihelQuZu6zSdIDGY5eKVIafUbYttfJXJJT5PbV+WbDLcfXOGo4tGxOD9aUggsUE+S+KAtQeAJaEMylssMgZOwj/KSlCnr/DSRydZGPPr8EliefRJopzNrwhSYlvk6iihc7lNrri0E1QmNLvlHti2Vvp80hYpt5XctMUj6bcmQ4Z5+7XW9ig+bsyD5TsT6OTsud64AAK9PwU5pt151RWts6wwxF0hP0unXY/g/bGBGk4aKCBUeG3MZHRtq57RRduc7Cqu0AMFNISbHdW9I8ROn45tDqD3KheTsYd6FIs7VYMeMrenjZ+OU6CsDB9ennggDnYtFLpk/yIwQ/HST9fFMU0FSe4biMJGhjDgkXBW0Se/ahwa2wFOmiYFIHVeyp7qNDrYpqfIQ9NvBA8STF9aFp7V6PGLaQl+t9ndeNrLUn8j+czZxydOwMKzCs2N6GjbsOvjbSvlEuk3vNbNnNtB ReUrI5L2 g/ZVYsgOlUH69W6wyEwX3aXaxtC96jhEJxJpfdAfYxiCmALcIu2iZ6rKQiHMZU6YJrXJ3bz9bmHp42TAPhmxzt0u+gAlEj3nk1jxafdeGfqvwU8Q= 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 Wed, May 17 2023 at 14:15, Uladzislau Rezki wrote: > On Wed, May 17, 2023 at 01:58:44PM +0200, Thomas Gleixner wrote: >> Keeping executable mappings around until some other flush happens is >> obviously neither a brilliant idea nor correct. >> > It avoids of blocking a caller on vfree() by deferring the freeing into > a workqueue context. At least i got the filling that "your task" that > does vfree() blocks for unacceptable time. It can happen only if it > performs VM_FLUSH_RESET_PERMS freeing(other freeing are deferred): > > > if (unlikely(vm->flags & VM_FLUSH_RESET_PERMS)) > vm_reset_perms(vm); > > > in this case the vfree() can take some time instead of returning back to > a user asap. Is that your issue? I am not talking that TLB flushing takes > time, in this case holding on mutex also can take time. This is absolutely not the problem at all. This comes via do_exit() and I explained already here: https://lore.kernel.org/all/871qjg8wqe.ffs@tglx what made us look into this and I'm happy to quote myself for your conveniance: "The scenario which made us look is that CPU0 is housekeeping and CPU1 is isolated for RT. Now CPU0 does that flush nonsense and the RT workload on CPU1 suffers because the compute time is suddenly factor 2-3 larger, IOW, it misses the deadline. That means a one off event is already a problem." So it does not matter at all how long the operations on CPU0 take. The only thing which matters is how much these operations affect the workload on CPU1. That made me look into this coalescing code. I understand why you want to batch and coalesce and rather do a rare full tlb flush than sending gazillions of IPIs. But that creates a policy at the core code which does not leave any decision to make for the architecture, whether it's worth to do full or single flushes. That's what I worried about and not about the question whether that free takes 1ms or 10us. That's a completely different debate. Whether that list based flush turns out to be the better solution or not, has still to be decided by deeper analysis. Thanks, tglx