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 8211AC61DF4 for ; Fri, 24 Nov 2023 08:19:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F11076B0677; Fri, 24 Nov 2023 03:19:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EBFE26B0678; Fri, 24 Nov 2023 03:19:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D877B6B0679; Fri, 24 Nov 2023 03:19:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C92A86B0677 for ; Fri, 24 Nov 2023 03:19:17 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 97CC98138F for ; Fri, 24 Nov 2023 08:19:17 +0000 (UTC) X-FDA: 81492147954.20.B7C4A6E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id E383840015 for ; Fri, 24 Nov 2023 08:19:15 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XXs+mMJG; spf=pass (imf01.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700813956; 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=v1eS37B2uoFmrwcBSrHqtcMz4RvWuoz94xX3ap5MTLo=; b=hMFr2dwYpZh+I05zFc/auFMHJuFXlGwedvNV5S59jf6cX1cuStaUh+RM1Q5bc+TF6LcqMQ nYGFY0CbrIo3idgZxK0e18rCNlaphfRutOLm3Yz1ekK+fjIKEHzVxBUqSilsWwxQwe6fP4 yd3Usnd+FsrXzs8piD1yQaTQi15MP+Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700813956; a=rsa-sha256; cv=none; b=WbuPLgiKsW5nN79gYWnlgJLtPVOHNugQ9bwnPfg+cHJqNQTD2Z4EwUdAvOxmfbNWnWQkEb 8Oaw24Zd2vt2PAecc0h0Kx7yL+BOlzHtxUu1Nkx05Y7wWdnM36xNZRcJE/LP4eiVBNYcHs mb9EYTDC8AQ+Vs4AR4wkjBn1DvzkmnM= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XXs+mMJG; spf=pass (imf01.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F25ED61FEF; Fri, 24 Nov 2023 08:19:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B288C433D9; Fri, 24 Nov 2023 08:19:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700813954; bh=r0jJ6NYuoUAc6x48eoCiJUxmyoGuCEuvMzB7D/Sb8+4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XXs+mMJGkZJwl7lIbWcJ8egMkYzH1x9vLsBdwIfm1ong7POe91YWeP4fLxRSnmm58 ALWKq+0PKbMjtYiIc21xK/RajleEWaV/Wafu2Si3FuLuJXPxDDDfO0UaDjRPjOflNY XFhWty4czKGTzMYKDPysf6zMNVlvHaqAHcifN69iDurSaELSgZ5BSTo9T9kV9viWAW e1mpPDf4Rlza2OjdnJ2h2Zsxw0FAs2NLGAmE+1sZDyDFqj2StFZ2MdjYbAZ5rIDnjD DjDA8fQHW7EAeEojurlmnyVGQXWsNQxRbi7yDjvGNZziislZdKvQRC+2lL1uRcAXaI LKjkQwsEIKwWA== Date: Fri, 24 Nov 2023 10:19:00 +0200 From: Mike Rapoport To: Serge Semin Cc: Thomas Bogendoerfer , Andrew Morton , Matthew Wilcox , Alexey Malahov , Arnd Bergmann , Aleksandar Rikalo , Aleksandar Rikalo , Dragan Mladjenovic , Chao-ying Fu , Jiaxun Yang , Yinglu Yang , Tiezhu Yang , Marc Zyngier , linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/7] mm/mm_init.c: Extend init unavailable range doc info Message-ID: <20231124081900.GG636165@kernel.org> References: <20231122182419.30633-1-fancer.lancer@gmail.com> <20231122182419.30633-6-fancer.lancer@gmail.com> <20231123101854.GF636165@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 1ajxu5rb4suwqs4ss7asdn8x5uyk4ny7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E383840015 X-Rspam-User: X-HE-Tag: 1700813955-290902 X-HE-Meta: U2FsdGVkX1/KWTBquwfVxoxNDjBlXqeOSO3wGPQ6sO++PJtfI99c0XrPALPxCKe7lZ97Bj6DgB+ayPjARDWLR/MCh2nX+T/yo3R24lpqm9x36/eZcVECiceaDs6pMABFnFnovT4ZqgePNCcazfk12ZhE1pX9cymz8vadsSCXVbIl8BKei5fCXBNG+b1YW2VmihkfYCamcmWGQ0Gowm9oVyyWK0k70fchACRuAosBVPlnnuRQ6iTAXLcVyb5H4HJKR3+bqwSgrRWPMxnnJfnP9TaT6NsOHbIUHycfLJitzkZ907K5GZlfSSoBv76jf4yuxTxnwaonLWW8ncwWO0+Sr3V0kOhFCNXJrHY3OV2bXORQdB1SbY0h0CC3S5WBoGyHt2MWac6AEOoX9UKIGImlDbKNlFJE8I8OorrOKeF+XRBGUcXHAhwLIKXD4aWxXJVmbeZ6nQ66kL5gz9ktZm+Oa+qjHe1b0bQt/Q/YQCJuQ736xj+72mdMAtruWRLa8bvFv0lyWwNqE5pTScwcXzxWtkHkNJw7Fdt/Q5mQylCk9QeVnlAnMhCk3D7X9wQ20CwwHgl5Z3qc5Fua64gbZNzVV2On6tszYkv/wQh2E7DnJBk384BboLJTDMLZpl0TtfEmSyP395+HUNyIZNTtj9pVTdaXueCi+5pUbR7lnCXKrb27+SaqXMMWJ0hgVVu+9WBUPyp7UPLnWAsC/D+BujHSx8lgjYrblokp7Igtam+JAJE0SxBhBvdBUea0SK5HdH2D4Zj9PEZnQVufXWJAPJTAANOiVaacdhyrVY1QneUgj/cWkbdGR5lOOHKrmN1i7+IFEDcrAZ5iWWH7ELpiOV+EVPeNBYe6LRlOzPCGS0kZqR1jkhmEQ8/sy7RNA17HgxMIOFuMfBWNYCsHe+i+KPoedkewaeZK0FHqGU/ve8HeYXbWQZkc2b3mx1QNsjXRJ7kLbgZOAIoxSDbyEAlHArT G7lyWWKm LmCtf8+0vi8RoHcJ0SPxKD5lPQKlkX72iJ525iXytjCNnxr0u2IDWM0Czx0Z7PmfWcvp/22f5ONnraOilaS8fnTKYEoA+2B2zZSluVHkH76V8ELEOT2LhMik9no3KE5d50SS68hz/OG5pMeHkiwTg5eYbG+dGXmSsUPyIRSTJhe0sj1/rPHJr2VERmIEFAkqMfOFGO4OQxVgLTpFRujzxYOn4skCeRq1VkAdbrTeMhtSOOjMCN0QzRiELAdBvgl27ZwfOlDgoNyf3JQghv0xELnVTYGMYii6jM8YOiUmgwCylvjRA0i4pkr8Wi8X+uiLEmzNlP/4cvV7SfCVTOZmqM5mfQQ== 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 23, 2023 at 01:42:39PM +0300, Serge Semin wrote: > On Thu, Nov 23, 2023 at 12:18:54PM +0200, Mike Rapoport wrote: > > On Wed, Nov 22, 2023 at 09:24:03PM +0300, Serge Semin wrote: > > > Besides of the already described reasons the pages backended memory holes > > > might be persistent due to having memory mapped IO spaces behind those > > > ranges in the framework of flatmem kernel config. Add such note to the > > > init_unavailable_range() method kdoc in order to point out to one more > > > reason of having the function executed for such regions. > > > > > > Signed-off-by: Serge Semin > > > > > > --- > > > > > > Please let me know if the IO-space pages must be initialized somehow > > > differently rather relying on free_area_init() executing the > > > init_unavailable_range() method. > > > > > Maybe I'm missing something, but why do you need struct pages in the > > IO space? > > In my case at the very least that's due to having a SRAM device > available in the middle of the MMIO-space. The region is getting > mapped using the ioremap_wc() method (Uncached Write-Combine CA), > which eventually is converted to calling get_vm_area() and > ioremap_page_range() (see ioremap_prot() function on MIPS), which in > its turn use the page structs for mapping. Another similar case is > using ioremap_wc() in the PCIe outbound ATU space mapping of > the graphic/video cards framebuffers. ioremap_page_range() does not need struct pages, but rather physical addresses. > In general having the pages array defined for the IO-memory is > required for mapping the IO-space other than just uncached (my sram > case for example) or, for instance, with special access attribute for > the user-space (if I am not missing something in a way VM works in > that case). No, struct pages are not required to map IO space. If you need to map MMIO to userspace there's remap_pfn_range() for that. My guess is that your system has a hole in the physical memory mappings and with FLATMEM that hole will have essentially unused struct pages, which are initialized by init_unavailable_range(). But from mm perspective this is still a hole even though there's some MMIO ranges in that hole. Now, if that hole is large you are wasting memory for unused memory map and it maybe worth considering using SPARSEMEM. > -Serge(y) > > > > > > --- > > > mm/mm_init.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/mm/mm_init.c b/mm/mm_init.c > > > index 077bfe393b5e..3fa33e2d32ba 100644 > > > --- a/mm/mm_init.c > > > +++ b/mm/mm_init.c > > > @@ -796,6 +796,7 @@ overlap_memmap_init(unsigned long zone, unsigned long *pfn) > > > * - physical memory bank size is not necessarily the exact multiple of the > > > * arbitrary section size > > > * - early reserved memory may not be listed in memblock.memory > > > + * - memory mapped IO space > > > * - memory layouts defined with memmap= kernel parameter may not align > > > * nicely with memmap sections > > > * > > > -- > > > 2.42.1 > > > > > > > -- > > Sincerely yours, > > Mike. > > -- Sincerely yours, Mike.