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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11F89C4CECE for ; Fri, 13 Mar 2020 14:46:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BE00620746 for ; Fri, 13 Mar 2020 14:46:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE00620746 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 370AF6B0005; Fri, 13 Mar 2020 10:46:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 321746B0006; Fri, 13 Mar 2020 10:46:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 237386B0007; Fri, 13 Mar 2020 10:46:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 0B7FB6B0005 for ; Fri, 13 Mar 2020 10:46:32 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A43C0180ACEEB for ; Fri, 13 Mar 2020 14:46:31 +0000 (UTC) X-FDA: 76590614982.28.hen97_73233ffee2714 X-HE-Tag: hen97_73233ffee2714 X-Filterd-Recvd-Size: 3215 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Mar 2020 14:46:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1A3D4AC46; Fri, 13 Mar 2020 14:46:29 +0000 (UTC) Subject: Re: [PATCH v2] mm/sparse.c: Use kvmalloc_node/kvfree to alloc/free memmap for the classic sparse To: Matthew Wilcox , Wei Yang Cc: Baoquan He , linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, akpm@linux-foundation.org, david@redhat.com References: <20200312130822.6589-1-bhe@redhat.com> <20200312133416.GI22433@bombadil.infradead.org> <20200312141826.djb7osbekhcnuexv@master> <20200312142535.GK22433@bombadil.infradead.org> <20200312225055.ksn4ujtkpjgkqiaf@master> <20200313000041.GM22433@bombadil.infradead.org> From: Vlastimil Babka Message-ID: Date: Fri, 13 Mar 2020 15:46:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200313000041.GM22433@bombadil.infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 3/13/20 1:00 AM, Matthew Wilcox wrote: > On Thu, Mar 12, 2020 at 10:50:55PM +0000, Wei Yang wrote: >> On Thu, Mar 12, 2020 at 07:25:35AM -0700, Matthew Wilcox wrote: >> >Yes, I thought about that. I decided it wasn't a problem, as long as >> >the struct page remains aligned, and we now have a guarantee that allocations >> >above 512 bytes in size are aligned. With a 64 byte struct page, as long >> >> Where is this 512 bytes condition comes from? > > Filesystems need to do I/Os from kmalloc addresses and those I/Os need to > be 512 byte aligned. To clarify, the guarantee exist for every power of two size. The I/O usecase was part of the motivation for the guarantee, but there is not 512 byte limit. But that means there is also no guarantee for a non-power-of-two size above (or below) 512 bytes. Currently this only matters for sizes that fall into the 96 byte or 192 byte caches. With SLOB it can be any size. So what I'm saying the allocations should make sure they are power of two and then they will be aligned. The page size of 64bytes depends on some debugging options being disabled, right? >> >as we're allocating at least 8 pages, we know it'll be naturally aligned. >> > >> >Your calculation doesn't take into account the size of struct page. >> >128M / 64k is indeed 2k, but you forgot to multiply by 64, which takes >> >us to 128kB. >> >> You are right. While would there be other combination? Or in the future? >> >> For example, there are definitions of >> >> #define SECTION_SIZE_BITS 26 >> #define SECTION_SIZE_BITS 24 >> >> Are we sure it won't break some thing? > > As I said, once it's at least 512 bytes, it'll be 512 byte aligned. And I > can't see us having sections smaller than 8 pages, can you? >