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 D6FB1C77B7F for ; Wed, 17 May 2023 10:53:03 +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:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JarNxm0LEBRmPTJgHgHVYSRX5RsFh7yHvqFXlS9I24I=; b=DMbe/2e9PXu7QN udk4g1uAQUx1fZdW/IeI23pTcDdN7GtILPPbqlVWW0a0JrEZ6QQu6TlSwLMzrKHa8KuPcaeLi9WYJ WzkNYkt6TZjhjTpacBnTNmCCEqco65rr+CEyUmL1Lk37eCRhyGTVfQeMLK0VPoTb4C95Rkw2lK4/V bDXvR8nIjDjw8AraUGcY2q24M+QjM8DFK/wHWAWaimvbyXIYISm3DIkv2rRZE4WSH0OI0baamite3 eBzjLFMstdWejIOSUNGC1MaCgMScHUo7rlqoccJi5QuRJlEiwD2D0nGOJNsAo5dvSA/6mKAOH7pod WTKd/RxWFIY2r052P9Ew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzElr-009Uam-2f; Wed, 17 May 2023 10:52:39 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzElp-009UYL-0t for linux-arm-kernel@lists.infradead.org; Wed, 17 May 2023 10:52:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684320752; 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=ypgh9nYJ7cN0U0SyanYmSIA/OBRRXNRPNSCafyHDX3c=; b=VTjcg6cEsgaKlNBiyaIPLPHdC5xYIweRE1k4dSEZw92/bpMQAaBngYN13kFfvBShLuOcf+ 94OkDo4DuMOu1jAdYMMVy/IyM2WEkjUy4lZr+yRDzDLhWgNvkDFaWmBYrMbou7stUGIpz/ rdR3CwK3N2Dy4WL2iSvcXNVEUGYpKtU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-294-_rhXu5noP32h8Ax73Q5PvA-1; Wed, 17 May 2023 06:52:29 -0400 X-MC-Unique: _rhXu5noP32h8Ax73Q5PvA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E6FFE868A00; Wed, 17 May 2023 10:52:28 +0000 (UTC) Received: from localhost (ovpn-12-79.pek2.redhat.com [10.72.12.79]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 047B8492C3F; Wed, 17 May 2023 10:52:27 +0000 (UTC) Date: Wed, 17 May 2023 18:52:24 +0800 From: Baoquan He To: Thomas Gleixner Cc: "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges Message-ID: References: <87r0rg93z5.ffs@tglx> <87ilcs8zab.ffs@tglx> <87fs7w8z6y.ffs@tglx> <874joc8x7d.ffs@tglx> <87r0rg73wp.ffs@tglx> <87edng6qu8.ffs@tglx> <87y1ln5md2.ffs@tglx> MIME-Version: 1.0 In-Reply-To: <87y1ln5md2.ffs@tglx> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230517_035237_402753_61CAD88E X-CRM114-Status: GOOD ( 25.30 ) 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 05/17/23 at 11:38am, Thomas Gleixner wrote: > On Tue, May 16 2023 at 21:03, Thomas Gleixner wrote: > > > > Aside of that, if I read the code correctly then if there is an unmap > > via vb_free() which does not cover the whole vmap block then vb->dirty > > is set and every _vm_unmap_aliases() invocation flushes that dirty range > > over and over until that vmap block is completely freed, no? > > Something like the below would cure that. > > While it prevents that this is flushed forever it does not cure the > eventually overly broad flush when the block is completely dirty and > purged: > > Assume a block with 1024 pages, where 1022 pages are already freed and > TLB flushed. Now the last 2 pages are freed and the block is purged, > which results in a flush of 1024 pages where 1022 are already done, > right? This is good idea, I am thinking how to reply to your last mail and how to fix this. While your cure code may not work well. Please see below inline comment. One vmap block has 64 pages. #define VMAP_MAX_ALLOC BITS_PER_LONG /* 256K with 4K pages */ > > Thanks, > > tglx > --- > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2211,7 +2211,7 @@ static void vb_free(unsigned long addr, > > spin_lock(&vb->lock); > > - /* Expand dirty range */ > + /* Expand the not yet TLB flushed dirty range */ > vb->dirty_min = min(vb->dirty_min, offset); > vb->dirty_max = max(vb->dirty_max, offset + (1UL << order)); > > @@ -2240,13 +2240,17 @@ static void _vm_unmap_aliases(unsigned l > rcu_read_lock(); > list_for_each_entry_rcu(vb, &vbq->free, free_list) { > spin_lock(&vb->lock); > - if (vb->dirty && vb->dirty != VMAP_BBMAP_BITS) { > + if (vb->dirty_max && vb->dirty != VMAP_BBMAP_BITS) { > unsigned long va_start = vb->va->va_start; > unsigned long s, e; When vb_free() is invoked, it could cause three kinds of vmap_block as below. Your code works well for the 2nd case, for the 1st one, it may be not. And the 2nd one is the stuff that we reclaim and put into purge list in purge_fragmented_blocks_allcpus(). 1) |-----|------------|-----------|-------| |dirty|still mapped| dirty | free | 2) |------------------------------|-------| | dirty | free | 3) Handled by free_vmap_block(), and vb is put into purge list. |--------------------------------------| > > s = va_start + (vb->dirty_min << PAGE_SHIFT); > e = va_start + (vb->dirty_max << PAGE_SHIFT); > > + /* Prevent that this is flushed more than once */ > + vb->dirty_min = VMAP_BBMAP_BITS; > + vb->dirty_max = 0; > + > start = min(s, start); > end = max(e, end); > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel