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 6DD0BC6FD1D for ; Tue, 21 Mar 2023 11:31:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9606A6B0075; Tue, 21 Mar 2023 07:31:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 910186B0078; Tue, 21 Mar 2023 07:31:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D88A6B007B; Tue, 21 Mar 2023 07:31:09 -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 6AB4C6B0075 for ; Tue, 21 Mar 2023 07:31:09 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 324A51A02BB for ; Tue, 21 Mar 2023 11:31:09 +0000 (UTC) X-FDA: 80592689058.16.D942106 Received: from elvis.franken.de (elvis.franken.de [193.175.24.41]) by imf29.hostedemail.com (Postfix) with ESMTP id 524EE120010 for ; Tue, 21 Mar 2023 11:31:06 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of tsbogend@alpha.franken.de designates 193.175.24.41 as permitted sender) smtp.mailfrom=tsbogend@alpha.franken.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679398267; 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; bh=WLH45vXhfTCnFsjp6lAqB54hpKU0NAE15do8R+jBsZo=; b=PKFuCqrsD0OeqLgzxfgGZcrOWjJagyduR9WNfg1blFhFdqbj7uC1MXxxGeWBsRGL9g/vhV EpBFJ+u1jFrCnw6HIMB6nycT3foqI7q/kSS7QM588nwajiclWgkbByTASL8m2GwtXgA/mM 4S4kGfysTBrMdmHEHIL+UeKwnTXKH5Q= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of tsbogend@alpha.franken.de designates 193.175.24.41 as permitted sender) smtp.mailfrom=tsbogend@alpha.franken.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679398267; a=rsa-sha256; cv=none; b=1KgAszEG3ZC/SgZVq7TqpHn3iepZ/92nWNjqBgu10MS9NJXidXEVWshJhejybPgq4o6D9H W6xxKY2rQrtnQRE5ohuCYChvHV4s4HJVC8KU1RsmNXLWcZ5EQbJfyJYPYf0PbYJ64zLClD /2bGutuIy68dpWZ2dyrRg5bv0OajuAA= Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1peaCj-0003H6-00; Tue, 21 Mar 2023 12:31:01 +0100 Received: by alpha.franken.de (Postfix, from userid 1000) id 0EE4EC1B11; Tue, 21 Mar 2023 12:30:16 +0100 (CET) Date: Tue, 21 Mar 2023 12:30:15 +0100 From: Thomas Bogendoerfer To: Matthew Wilcox 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: <20230321113015.GA11292@alpha.franken.de> 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: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 524EE120010 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: i1ncrt1b78sra36o4r7byqd36nyakzxg X-HE-Tag: 1679398266-865495 X-HE-Meta: U2FsdGVkX186dDkz6xE/godD4nbGsYD636Dv6IFxce3zKGZty+9tI7xxof2o3uTcWz4SesHoDTNUqJ2nfqsuLnklNtgl5bzsU8CXt2nYBIpT5wElOJASZi5mffg6YjAnL5CeOYkIhhYjgdVTnaGBK5Tqi8cGGLSgP1ZTxasI9qpKnjaa07rbJurvlR3CVKJTwYfFEa/8jZf0zPcx6dRpooJVYU3E9bBELmavsQTUqLC8E8VWAltcBwGfJl8eamdODWk0bilvGcWrn1yYol6D3HeV9JJkWLiifDOyXYOz1nviZ+PhQwIgq7h7wjKF5UpEJV3IDMg/12/QTN6aG1mpOQH/6WCMeefJSjef/QMBwrbxUS73vYHuM18D7mZkTD4umcjvSgie5UIWLeQoTkAjBEwOHozMZ+za6tsZuAlKQbnynNO5yYh8oD8ZirTVci9mmhWZIUw5oMHrc0eSn0+qgSLE7FI26dC/ZTaEJeCqTnPCTSNOA/fJBsiIY+C9xrgtupSM5j8wZi8gZy2ktgg58HJlgE0AqltWz9FKJVeezmU3+ngqKHxKzeMetXJfapdusZCdlFGWr015jIFSANsUHuJ8zATtmKuqdkdli46XaD8h301FlHb6dzi1SrqiVjnlJVkNmqm3bdjYi6M1k8R7TVLVj6b86E/+meRrIN24ijtHI6nWqCxFOajkwRSD9p5PzSoJxh73mhi17iBKEFwBq5qZYv7rUXgOfr9m80ELHY6+HWPAXNDJFGVuxW61urTP1EjVvZmhV9SIdJ/nd4GWE0XZsTQrqDs5akIOltd/dQjWJaKIK+Uf6ZiHF6jxH826ApXCKeosFhxlpRS3AjBME/X26vxltEAudYNLZFIou5kEnLheypAEbZffD68kKTBGlxAiCybbpQp6kLQDHcJ51uJhqWVef++yciXFAwJx1V7vJ0orDevjz93SMHBs0zh6X6oibEc1pNRgwDGlTOT keJ/Ko7U msONaa9I4bl46jKH/pyB3XXyQmMgcAUEOus0ATbkTkliSzjk= 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 08:16:36PM +0000, Matthew Wilcox wrote: > 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. biggest TLB I could find is 256 entries, which can map 512 pages. > 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. ic > 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. that would help to optimize the case. But update_mmu_cache_range needs to do __update_tlb() for every page to avoid stale data in TLB. If I understood correctly only the way how TLB updates are done changed, so there shouldn't be performance regressions. And optimizing like moving the looping over the pages into __update_tlb() could be done in a second step. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]