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 B0D41C77B7A for ; Fri, 19 May 2023 17:03:21 +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=TIp2iT9PAbZXfHVFvXDly3QrjzBHC5V3vFIOWPNg7Tg=; b=DO4NhOedcBbR2C 4UPZfX6qRwUwQZfISnBloozrIYttPKt6XiFLsU50b7q0Hay+bZ+cJqF0X1+Xn0Y8lcY3XrfmMu3wB v5IrPGy5sb1WVOrphdjs8M39R0Y7AlivQLuYalsFt0bJ/ZrJTZLRKpIbsPhBrVx2sTpWh6rUY5PWn VeR5GyMBJ81q0nqb+R9jTNocb7tCsGsrgepgBb6ZSzvTwNRWRAsPPPGc4SuVPiQTlkl1e8aemUhzn F3dM+1u4S2peZgP/LN4f8JaFRjiz5MsP38PV0/H6gnFm+gBTN4+yIPAGn7TFkuF8g0XApm+hlhpSr HCmRUzjkV6kUbsvfqHXA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q03VM-00GnPo-2y; Fri, 19 May 2023 17:03:00 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q03VK-00GnOQ-17 for linux-arm-kernel@lists.infradead.org; Fri, 19 May 2023 17:02:59 +0000 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4f27977aed6so3921545e87.2 for ; Fri, 19 May 2023 10:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684515773; x=1687107773; 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=/5gWWnU6rWDEqQdM4br3GFqSxtcuOPR/FtdJtjJJ2uw=; b=fIlCc7KmT73/bJUnVx2lsl8//G9pquk/8PdZb0Sz4NHUvUgszaGaH/tjP8dLMcPkWd xCWMPPKlOfLcWtKnzi7XTn7MxgbQSneHrhmLePusAIoaoLyqxQq4dbLOuLLJt5HwoEWR jzQRmUUOhKrXUkIwlOoVl7sMqpWvo5yzgfHDRY3NbHGHy+WQCtDHdhgF5BOVpDrnzaET CAqx5s/ocslqk6xOLERLI3BHDijySgJvGBlb30tFLT8ZcYV7cUT5GcTBolNjIKctbgKr BrR6qU1oHl0issmXHvq7xJspCzeLA2IsgQMjOYFQPqUs9rD3ExwvjgWy3QlZze8h5DDB S4PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684515773; x=1687107773; 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=/5gWWnU6rWDEqQdM4br3GFqSxtcuOPR/FtdJtjJJ2uw=; b=BhKDmUwEOOKPRGIdPeqp/H2uok9i5/odG+Zyo4OHYjtcqEPBLGrGM/Iy+QYwxvKJQH iqe8g3uyNg8TXg/gSq9x0VpQQP5ZufUWPmHGcTdQMh8dhWxZHlml8xzMwGGYEyqT3z/Z OqPc2BdbwwTF2wt5s4E+uo8C2xg7rfbX/H8YUGjVAPlv/876iSJ+pB3KxU694gWjF4eC YyFHmtO9vZFupyGchWOGFVJEwQJ1iSayDzCAkA/fq2I6fsC7kYe1cKVVsWg5+WEqGSn3 bu9b8lCOlsrmfV1Iv1sh4kdR6u+wDWKvh6K7ICqldRGCBx/pNUKgYAWQ9A0hieFLn47R llNA== X-Gm-Message-State: AC+VfDxkFhsZev3qMjeZXlNUkgohCHFYrnDzkmY6BZmQTF+/186vB3yg /CIlc7xZn3XoyYa6F47FmUg= X-Google-Smtp-Source: ACHHUZ4xNNENafdqB6Nyo0fUbPbeRaAC5IKI7JtUd1m6Vn1vf5HZVFWpWnc1BLK7tODJ66j4zbGtbQ== X-Received: by 2002:ac2:511a:0:b0:4ec:844e:7b85 with SMTP id q26-20020ac2511a000000b004ec844e7b85mr1101667lfb.25.1684515772481; Fri, 19 May 2023 10:02:52 -0700 (PDT) Received: from pc636 (host-90-235-19-70.mobileonline.telia.com. [90.235.19.70]) by smtp.gmail.com with ESMTPSA id f5-20020ac251a5000000b004f2532cfbc1sm660938lfk.81.2023.05.19.10.02.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 May 2023 10:02:52 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 19 May 2023 19:02:49 +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: <87leho6wd9.ffs@tglx> <87o7mj5fuz.ffs@tglx> <87edne6hra.ffs@tglx> <87lehk4bey.ffs@tglx> <87fs7s46z9.ffs@tglx> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87fs7s46z9.ffs@tglx> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230519_100258_381603_D80545B9 X-CRM114-Status: GOOD ( 35.06 ) 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 06:32:42PM +0200, Thomas Gleixner wrote: > On Fri, May 19 2023 at 17:14, Uladzislau Rezki wrote: > > On Fri, May 19, 2023 at 04:56:53PM +0200, Thomas Gleixner wrote: > >> > + /* 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! > > Seriously, you think you need to demonstrate that to me? Did you > actually read what I wrote? > > "I understand why you want to batch and coalesce and rather do a rare > full tlb flush than sending gazillions of IPIs." > Yes i read it. Since i also mentioned about IPI and did not provide any data, i did it later, just in case. I shared my observation and that is 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. > > ARM32 has a full flush as does x86. Just ARM32 does not have a cutoff > for a full flush in flush_tlb_kernel_range(). That's easily fixable, but > the underlying problem remains. > > The point is that coalescing the VA ranges blindly is also fundamentally > wrong: > > > start1 = 0x95c8d000 end1 = 0x95c8e000 > start2 = 0xf08a1000 end2 = 0xf08a5000 > > --> start = 0x95c8d000 end = 0xf08a5000 > > So this ends up with: > > if (end - start > flush_all_threshold) > ipi_flush_all(); > else > ipi_flush_range(); > > So with the above example this ends up with flush_all(), but a > flush_vas() as I demonstrated with the list approach (ignore the storage > problem which is fixable) this results in > > if (total_nr_pages > flush_all_threshold) > ipi_flush_all(); > else > ipi_flush_vas(); > > and that ipi flushes 3 pages instead of taking out the whole TLB, which > results in a 1% gain on that machine. Not massive, but still. > > The blind coalescing is also wrong if the resulting range is not giantic > but below the flush_all_threshold. Lets assume a threshold of 32 pages. > > start1 = 0xf0800000 end1 = 0xf0802000 2 pages > start2 = 0xf081e000 end2 = 0xf0820000 2 pages > > --> start = 0xf0800000 end = 0xf0820000 > > So because this does not qualify for a full flush and it should not, > this ends up flushing 32 pages one by one instead of flushing exactly > four. > > IOW, the existing code is fully biased towards full flushes which is > wrong. > > Just because this does not show up in your performance numbers on some > enterprise workload does not make it more correct. > Usually we do a flush of lazy-areas once the lazy_max_pages() threshold is reached. There are exceptions. When an allocation fails, we drain the areas(if there are any), second is a per-cpu allocator and last one is vm_reset_perms() when "vm" is marked as VM_FLUSH_RESET_PERMS. As for your description i totally see the problem. -- Uladzislau Rezki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel