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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE36FC7618A for ; Sun, 19 Mar 2023 20:16:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32ED86B0075; Sun, 19 Mar 2023 16:16:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DF5D6B0078; Sun, 19 Mar 2023 16:16:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CDAF6B007B; Sun, 19 Mar 2023 16:16:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0D1ED6B0075 for ; Sun, 19 Mar 2023 16:16:44 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DFC60C03AE for ; Sun, 19 Mar 2023 20:16:43 +0000 (UTC) X-FDA: 80586755886.17.6F3E723 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id 93CC4C000F for ; Sun, 19 Mar 2023 20:16:41 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="pCUH/YZz"; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679257002; a=rsa-sha256; cv=none; b=2tJ8ZFywbrnQjZ7ys/rJIhgNwosIu6GEcoALyP0R/3qCDtzYtQqix9dtGoE//IQsCQ3AJ/ bWqtbphZLtXENxWIPEzV2rP9KzgwvONNcG8foHowvcShuGIXVeTfOijQt7y4qkTy5jYaFV k/LX76lmvg56lnk11o6MM9MB0YLf4AM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="pCUH/YZz"; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679257002; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wRqe5vhNuDvhiga63gy5h46j0EPNOE641nmmHAf6FaI=; b=mbznzj2/QJWMmRJ/ixnVWSGMKsOrBKyYfnL0Fw6F1tHf50udTFtCeqCveePtc7a2bdl/Id IqAoa0/rg6ojUwkue2ww11oLM5KygkDVsJSvL76+ZO0BaoAq+/9y47Or7vCE1LUyxvO7dQ kl5wmM56CfVu9hJkIKRsAnMQMy/Lrbg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=wRqe5vhNuDvhiga63gy5h46j0EPNOE641nmmHAf6FaI=; b=pCUH/YZz/lU+SgEhgoEzLz+lLj /Qm5GtTRnpRcdY1BxLzMRD3AEnxa5FXFcW+vN1e4cvj8ONuA5cgs4/4VVIj0K/1OyyI2Xg4HJHJwr NpTE8hnH70C8TPXWhBxKDCUi7H8jD/PXMPEhjlpkrMGD7l+y3KWBFAYdoJpr9w2oyXl78pMo9A+B1 QNCUZUDNAE97Uc+aeahPuGJG61pV+jsiGY5HRO3DIiY8sieV8LV4Sq0v3egSK8lAoJjTnqZd86dmj 0Ws/GeNb2zzXk3IVFyD9/mRTYQoPQ1umqi1+NhDIDil+By5ywmrm7HyzlcSkmqB6bc2RdiQE41cNp FwjoJQ4w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pdzSG-000MRs-5r; Sun, 19 Mar 2023 20:16:36 +0000 Date: Sun, 19 Mar 2023 20:16:36 +0000 From: Matthew Wilcox To: Thomas Bogendoerfer Cc: linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org Subject: Re: [PATCH v4 16/36] mips: Implement the new page table range API Message-ID: References: <20230315051444.3229621-1-willy@infradead.org> <20230315051444.3229621-17-willy@infradead.org> <20230315105022.GA9850@alpha.franken.de> <20230317152920.GA11653@alpha.franken.de> <20230319184536.GA6491@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230319184536.GA6491@alpha.franken.de> X-Rspam-User: X-Rspamd-Queue-Id: 93CC4C000F X-Rspamd-Server: rspam01 X-Stat-Signature: p6q61i1g1pt4r86mx4bwskpx7yrwpmyj X-HE-Tag: 1679257001-230401 X-HE-Meta: U2FsdGVkX18eR+V15W+cBvuuYSjW+gkt0ng+yFIcs0pME1la2KP50n6cYw0sW3bzu/jQ0yKEELdCpXLKNFrRSltJFISbb1t99SwYwIaufG8aoDEIkTs4MI4MwhSxTqGQ2sT9uoSG01rbIuUXtbH6jBFtK3fqxPBZ+Xbi6LnVHjUvJxGSfsUNSjSwYRIbY5CbFqt/Ol4TYko3LqRUzrch1Ac7zEZWroa0qM6R12E+RNveYe6qDddKkVKIXOdJZzUmZurMLViUOw0cHTcmVP3YSsX81UMzeV7Fe/E2rPB7vQAmL4ssOI7RrCODqQUTwIC6O/WAJiTpDz2AhRBlOKKdTQeYU1WmW+7rnnFg2Nps4Vmo3aQe816T8IyI0Sx1PWQU7Np/IhD6S+eBOs2rt2Ia0BxOWGRNbXJuzpSXfrw6N/TEFhR8TRc1oh/PEzV+U75/kAXnpZOjg5uazNQdUpGk3YEDknDgWOU50F8pKQwUdeQFsbTTmDcc/712RX/dfTOm1jlBPJ/hgyhv/96HBTr4WHz4lIgvQWaEsMgYUGd7k5qfPn6sHW2XYDK7nRaXgjCzRUa2rhF9rzvNyORv9LXjPCh2XpV7wrSxqs1oYoyolMdp5FvZHu9Nli75eobZxBuUc8jSoOwsL6BoH5xfGjPYkWa3EnV8w4L2l+d4uEJMsAG8BG4GgsFnF4j2TXNXt+wm/l38r81NMPb9qZX1FyVGUQs+PV2cEOnNesGWm0bDJesG1vkGYRy8GE+Meycom3K+92HeduF8Ihcpp+uHZTZTleLbg25sOpkG8HPUkv8f7Ni7gU9qm0n0pTNUxcACkP/lgwLOoJ23n5Iq3w/Dw6WSvtTnZ69vUDHZ8zx965lGG3gQh2dQN91ZBoJRQnkq2STskNACo3RgJ6LlR49DkdMf7x1T5yPgKJxfRwBr8m+VzARdZeh29tKb+4SyazcGkGRzFcc2JI8RHYMQu3jQPWp oXBGi2Su byQ6ohblWFr9L8DtAB44rcAGVxyh3M23FQcYhkh9kiP6CokwKhUBg92ehiIXuUwugXdAd+XLxBLCvD3Fv6Xfa2brOiz+H0o4gh+oQYJOwaC7H20bckrpWEL6mRNq0kzN3zE+jP/pUBImxtocX5lcorykRTg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Mar 19, 2023 at 07:45:36PM +0100, Thomas Bogendoerfer wrote: > On Fri, Mar 17, 2023 at 04:29:20PM +0100, Thomas Bogendoerfer wrote: > > hmm, not sure if that would help. R4k style TLB has two PTEs mapped > > per TLB entry. So by advancing per page __update_tlb() is called more > > often than needed. > > btw. how big is nr going to be ? There are MIPS SoCs out there, which > just have 16 TLBs... Oof. The biggest we're going to see for now is one less than PTRS_PER_PMD (that'd be a PMD-sized allocation that's mapped askew with 1 page in one PMD and n-1 pages in the adjacent PMD). That'd be 511 on x86 and I presume something similar on MIPS. More than 16, for sure. Now, this isn't a new problem with this patchset. With fault-around, we already call set_pte_at() N times. And we don't say which ones are speculative entries vs the one actually faulted in. But let's see if we can fix it. What if we passed in the vmf? That would give you the actual faulting address, so you'd know to only put the PTE into the Linux page tables and not go as far as putting it into the TLB. Open to other ideas.