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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 45EA1C77B7D for ; Wed, 17 May 2023 16:32:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rt/le3uvKGhL4l/qp4fF5Qz8zDRNK8nT5D1whyumF0E=; b=IugEVfhyN182OS 3kFXRvA5QFoaxrRDtAqCXS5VbsddTJPmiRaQYQAoDlUN5bp7W+I2Y5Vx+nmymww0UUkNIT1RXBj6R tfo62DVuahI6r0PJvF7tzMlh4PNc8EjLtGYFfdMpYubYQVikUXvEKi7TWRa25jhYz6ycHfluKXxPx q3mAFL3M/vG81jZzgtqedWDGWQJjNvaVwqqnenFUDr/tvjOyHJCoEgbZdEE7TFJLkEpy41m8kBsCh YE3CStnTPkN0maHqBhsIVhCwkqvEQLBDzTK2Mpsky4oJcP2aMpl2F7SrEzZqdqxxM2bB6qHyKqTo+ K170hfIUCWVQahXE2uag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzK4o-00ATsM-2Y; Wed, 17 May 2023 16:32:34 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzK4l-00ATqY-0B for linux-arm-kernel@lists.infradead.org; Wed, 17 May 2023 16:32:32 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230517_093231_236383_45CAFF39 X-CRM114-Status: GOOD ( 16.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel