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 621A8C77B7A for ; Wed, 17 May 2023 12:15:45 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/7yhsiA8PM0PcaHA3oAg308o0Xe9c58R5Sn+j/CnqNU=; b=cFqovbMMoLkMrx 4XD+zE37jRfO9rzGLoXM6wxsD3BW2882UG40PNblA1ok1jC7JAhXKVk00okob2WehRw+e7alyGMzN btBaGT6lSK21c6cIjhA0plSwR8wbBiV1ydVcDtKFNvELAX3lfjQ8bvRALAqmp7IHyAJ9GaDQIGHrm S5BN6xqlvOtzE/X+0892ScUUO5ThNgcAfBUe3Ujb3iLB4LG2GxL6ByHCfUfRNmbDWwy3Re3o32fjC jzGDE1ctAK2EINJisopLP3npxrzu/0Rnf8SPrfBTxjwLVNlz4jAa4da03Lig4flIa7o1WnQ/SU0R3 5Zo9VfFP2PQmNVyvwNRw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzG3s-009loB-1f; Wed, 17 May 2023 12:15:20 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzG3q-009lmt-08 for linux-arm-kernel@lists.infradead.org; Wed, 17 May 2023 12:15:19 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ac80da3443so6648531fa.0 for ; Wed, 17 May 2023 05:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684325715; x=1686917715; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=X1lQxUyzM4Rd/o4Wvs1eOyZlxtftGtmBvO8kh4mwGQw=; b=joVnh5EXMID6F3MrTXY5vgDF2FPG6wH9TeSpD7jfPJksnIdYsAbvVFWB+zhhYIW9MA jRG43y9kkK8FaMfxR/DIq6vlkMprm0SaxFQ8ZXfYHWXCcFgKH8MUw7Yt9wjSrMAH/Fad 4f3p6B/roTW/SxHcIVNsNyM33/rjnQo7JOTAeYHCxINWdDcjBTAIKrpIHWv4iVTlyIrE ovHxzSt8IqL5YOggA5iDAIFTvbNnb+TDBQgkDjPsurW8yHy9AT9lCO9vEL7sql0lPdtw fHW0EY9c5ay+tfhWZm8TfhfyuTHRtJQxqW7Ah1LRSlB286wmBJoFw8VLPfwrfBdgtD/q sK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684325715; x=1686917715; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X1lQxUyzM4Rd/o4Wvs1eOyZlxtftGtmBvO8kh4mwGQw=; b=iEltlXCoVjEb7Cxl2Sfu4zYAdXHgux8t629BQ7VMnzxea2PD2j12yRwWl4r/WaRaEU YLch0fAuo1pZz2T7sRAluEB4Z/I3zVETzvOJNFcViJsGyw4Awzzmvd80kASGHvPq/CeE slI0smRIN81kuTTWAPNA6a+zYWvMbR5gA6OU/H4R/02P9qd5LzClRt+Z180ZB5yH5SG/ HqndbAavJ/dxVV3x20YRFG5+N2B80P+gtY5qSGry2dNXXIzu+/iALzDqPdI2TE+1Ug2S hBeE/48UovenJKv67uwo6HJ6BJmFeTRUIyzRKy4nHWkQPnk62PS+/MUzCMj9bHXlApQi S8Xw== X-Gm-Message-State: AC+VfDzDColcZ/9Lbb3f5Ur5n6EJiGpJjZ+AHitdVHL0Wh+jWquoqjB8 cmNWSlchq4nXTWDp/uAA2u0= X-Google-Smtp-Source: ACHHUZ4WlyXWr8kjmzgFQrKv8K4OtwNkyDPC3iVfLqkqMsyJIZuveZXpA5fuTnF+vCQBqYIniDvgzg== X-Received: by 2002:a2e:9495:0:b0:2a8:b579:225b with SMTP id c21-20020a2e9495000000b002a8b579225bmr9517027ljh.40.1684325714713; Wed, 17 May 2023 05:15:14 -0700 (PDT) Received: from pc636 (host-90-235-18-147.mobileonline.telia.com. [90.235.18.147]) by smtp.gmail.com with ESMTPSA id v21-20020a2e87d5000000b002adb10a6620sm2836812ljj.107.2023.05.17.05.15.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 May 2023 05:15:14 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 17 May 2023 14:15:11 +0200 To: Thomas Gleixner 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 Message-ID: References: <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> <87leho6wd9.ffs@tglx> <87o7mj5fuz.ffs@tglx> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87o7mj5fuz.ffs@tglx> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230517_051518_085099_0684FFE3 X-CRM114-Status: GOOD ( 32.45 ) 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 01:58:44PM +0200, Thomas Gleixner wrote: > On Wed, May 17 2023 at 13:26, Uladzislau Rezki wrote: > > On Tue, May 16, 2023 at 07:04:34PM +0200, Thomas Gleixner wrote: > >> The proposed flush_tlb_kernel_vas(list, num_pages) mechanism > >> achieves: > >> > >> 1) It batches multiple ranges to _one_ invocation > >> > >> 2) It lets the architecture decide based on the number of pages > >> whether it does a tlb_flush_all() or a flush of individual ranges. > >> > >> Whether the architecture uses IPIs or flushes only locally and the > >> hardware propagates that is completely irrelevant. > >> > >> Right now any coalesced range, which is huge due to massive holes, takes > >> decision #2 away. > >> > >> If you want to flush individual VAs from the core vmalloc code then you > >> lose #1, as the aggregated number of pages might justify a tlb_flush_all(). > >> > >> That's a pure architecture decision and all the core code needs to do is > >> to provide appropriate information and not some completely bogus request > >> to flush 17312759359 pages, i.e. a ~64.5 TB range, while in reality > >> there are exactly _three_ distinct pages to flush. > >> > > 1. > > > > I think, all two cases(logic) should be moved into ARCH code, so a decision > > is made _not_ by vmalloc code how to flush, either fully, if it supported or > > page by page that require list chasing. > > Which is exactly what my patch does, no? > > > 2. > > void vfree(const void *addr) > > { > > ... > > if (unlikely(vm->flags & VM_FLUSH_RESET_PERMS)) > > vm_reset_perms(vm); <---- > > ... > > } > > > > so, all purged areas are drained in a caller context, so it is blocked > > until the drain is done including flushing. I am not sure why it is done > > from a caller context. > > > > IMHO, it should be deferred same way as we do in: > > > > static void free_vmap_area_noflush(struct vmap_area *va) > > How is that avoiding the problem? It just deferres it to some point in > the future. There is no guarantee that batching will be large enough to > justify a full flush. > > > if do not miss the point why vfree() has to do it directly. > > 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. -- Uladzislau Rezki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel