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 775F7C77B75 for ; Fri, 19 May 2023 15:15:34 +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=+URW6iZAdcc1CBkcjjYHfGmosOVZGgVaq+WMgaIZtN8=; b=0T+T268yHLf4z6 cnp1uIt1RLovEQXNSpfbNJGZbcdQcDNwuutRstbVMHZZ4huUI2lFYM9jJraSKtMmhxGuDv9lMW3+e BkWye9jYhLc9ufh0+mbmLQrajczYgJmbyuFrePgRSbHuRYjF8QF8FmM545+NMHpoi9Dl/qWZwJBNy TOdr4II5Mdl60NuW0HjxAkUE9eWpSA4qj7fxEr5PygZKwPbaMgEX4VI3SJPrNAOCBF91sF+aKj0WU aBzhsVLhyPVG6uT6U0vO07c3cfN2Ar25yAQ9V48lsVW0peeJqKJ5AhSpn4H3mT0p8tj9tFVXkQuyD igdGTzWLm9KZzHA0FMfw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q01p1-00GZzZ-08; Fri, 19 May 2023 15:15:11 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q01ow-00GZxV-36 for linux-arm-kernel@lists.infradead.org; Fri, 19 May 2023 15:15:09 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4f137dbaa4fso3983006e87.2 for ; Fri, 19 May 2023 08:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684509301; x=1687101301; 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=8e0yuqMeH77y385bGplR435cEZnwX7M3pem8aqlOD6A=; b=PC45RYhCU1F0/YsuxOc8oLePK8BRR/RpBAhY9uhKd8bJVOYLSroTsB2S23sDYEf9IU RKBXYztUznogYGoA/yOEdcPcIjkCyj8KDrwrECfbwvsmAgV85wZKTz7+OxDpoguK9aDV dNurrCoG3Zamyi4VMtkqlNQ3VitCXIt7HLdO0adExuBLqCoN/MLpLef4Ftbm9LZ4yqDw LBYf4FIVVAnz73Dt2AZPwWBG8SN1GV4ZV3tF6hRGoPDPdXi8IFdjINT3sZPXqya9JEaz VMuc9P7XWeCr5vtJhprVGS243g2iAMdFK5eHvxkReYyB6hDlUKmljmZUgAeSIIAgJz60 b0IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684509301; x=1687101301; 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=8e0yuqMeH77y385bGplR435cEZnwX7M3pem8aqlOD6A=; b=F6VGM/PAA1E6oU+ryp5qQkeI8SNo8wCt3+FUIUeaCEh0jtzartNARL0OsYJ7cn3OUA AerY79YyAmV/UjD4/ci5XzYAbi7zNAz4R2xCKNCiBmbYcrC68dYPuIVmJvsZpUl2l73k cWUjUs809GtC6kS26WwJR/ataRVSxsdKYu2flq+UizFnvotpIYQovhmNBGQwbv2JNH3T Fo6AMhCqQe7uub1D8lbHk3rwcKa6R2MrYlin+kVHu/iT/krfxE9lEk2rI6oJd5EJI9vm M5ow2vT68n3FOcWg7tUFtNw4xTFn6cNYPxdVvxBLF7Hf3hmXo+v7gD8b42JccwMwnsb+ IT2w== X-Gm-Message-State: AC+VfDzzmuQXxJ7NPmxH82iv2LWWf6meKnAV816YFJG19G2rzFxmp2LN FKNSwQ9GU9JMQ0kYfjAaDXo= X-Google-Smtp-Source: ACHHUZ7DUVYf6J9MIyc9ieuAXvzosS2fWbEpipG/OTZ5pUkMR84024z1M04pG54QVB6zrhoENipJmA== X-Received: by 2002:ac2:4430:0:b0:4f3:a99c:fbbe with SMTP id w16-20020ac24430000000b004f3a99cfbbemr1027456lfl.14.1684509301240; Fri, 19 May 2023 08:15:01 -0700 (PDT) Received: from pc636 (host-90-235-19-70.mobileonline.telia.com. [90.235.19.70]) by smtp.gmail.com with ESMTPSA id i13-20020a056512006d00b004eb44c2ab6bsm619596lfo.294.2023.05.19.08.14.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 May 2023 08:15:00 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 19 May 2023 17:14:58 +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, Nadav Amit Subject: Re: Excessive TLB flush ranges Message-ID: References: <87o7mk733x.ffs@tglx> <87leho6wd9.ffs@tglx> <87o7mj5fuz.ffs@tglx> <87edne6hra.ffs@tglx> <87lehk4bey.ffs@tglx> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87lehk4bey.ffs@tglx> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230519_081507_019796_5A6B91CD X-CRM114-Status: GOOD ( 22.62 ) 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 Fri, May 19, 2023 at 04:56:53PM +0200, Thomas Gleixner wrote: > On Fri, May 19 2023 at 12:01, Uladzislau Rezki wrote: > > On Wed, May 17, 2023 at 06:32:25PM +0200, Thomas Gleixner wrote: > >> 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. > >> > > Your issues has no connections with merging. But the place you looked > > was correct :) > > I'm not talking about merging. I'm talking about coalescing ranges. > > start = 0x95c8d000 end = 0x95c8e000 > > plus the VA from list which has > > start = 0xf08a1000 end = 0xf08a5000 > > which results in a flush range of: > > start = 0x95c8d000 end = 0xf08a5000 > No? > Correct. 0x95c8d000 is a min, 0xf08a5000 is a max. > > @@ -1739,15 +1739,14 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) > > if (unlikely(list_empty(&local_purge_list))) > > goto out; > > > > - start = min(start, > > - list_first_entry(&local_purge_list, > > - struct vmap_area, list)->va_start); > > + /* OK. A per-cpu wants to flush an exact range. */ > > + if (start != ULONG_MAX) > > + flush_tlb_kernel_range(start, end); > > > > - end = max(end, > > - list_last_entry(&local_purge_list, > > - struct vmap_area, list)->va_end); > > + /* Flush per-VA. */ > > + list_for_each_entry(va, &local_purge_list, list) > > + flush_tlb_kernel_range(va->va_start, va->va_end); > > > > - flush_tlb_kernel_range(start, end); > > resched_threshold = lazy_max_pages() << 1; > > That's completely wrong, really. > Absolutely. That is why we do not flush a range per-VA ;-) I provided the data just to show what happens if we do it! A per-VA flushing works when a system is not capable of doing a full flush, so it has to do it page by page. In this scenario we should bypass ranges(not mapped) which are between VAs in a purge-list. -- Uladzislau Rezki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel