Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp133264imm; Thu, 12 Jul 2018 15:46:44 -0700 (PDT) X-Google-Smtp-Source: AAOMgpezT/hP8rKDu773h+/PtS8mJIMjrQCtbrgIR6ck669MmMwG2qvAxkFGvs1saZ2hNc9YBWQB X-Received: by 2002:a62:8a83:: with SMTP id o3-v6mr4358414pfk.12.1531435604200; Thu, 12 Jul 2018 15:46:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531435604; cv=none; d=google.com; s=arc-20160816; b=vhPNhSuwEOx/N1uF5xxck91vJK14BJQQcGl0vV2zaU2CcUzlIayXZ2UC8FiVbGXjMR 65gCoQgCk9dSz8c8eQf975ci/WvG+hdhp6kyeYyGIcXcZgF4bRWL0gxZArNYpsyO2YVH yNcvUjo0Ia4B2q+chpDn8Jnr/+Fq6Cay5bOoz4nHHszkE6WtgL0c4Ui/sts+/zyod0BS UWmF/ur+ObD1J3z88nrkA3TShLDFSW8r1Bfor4os6tDSWJQVuqgA2fRwNENWuOo058D5 1pFnCxAzHAYbOiwUraefsjEIn7dk4XXXC+3ojpp5B6eYeTyg0xAZq+heNCs1hxV9VOMW DRNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=OMXB1B8DIJDPxP59e5clPKcNrTOuflQpHN0QB6sg5qo=; b=AgKFHePtF/pfUw6u62YR+6diMAwIvfb4M2EnR+TcW09aPlsj8fygwWNo0/a8flKJgI KRY23boX1c6LReT7p+XrqGRu+cgREp8giZONNPzAFjnrUQBKDEFcnftRw0zg0vsb8y9B yliggmbyHqXyE0SuswperdXSTF14dQKZIzZr5+Xp0EdJIkflMsI1XDVSDdDqiaaj4Op/ HaanKRz17CbqqTeYEpLV0ZhBj/hoUhH9wYzIUtdXgoZhinXt8fmt1o9EqlbNJjIRlOEi MNeoGQ/ID7aq3I4ztpOFJ6go0lrcHqTjpFdstm9BVf5qHURYlu/dIfJHrwjyiUbQWsIR 78gg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f28-v6si24838953pfh.33.2018.07.12.15.46.29; Thu, 12 Jul 2018 15:46:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387451AbeGLW5g (ORCPT + 99 others); Thu, 12 Jul 2018 18:57:36 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45544 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733234AbeGLW5g (ORCPT ); Thu, 12 Jul 2018 18:57:36 -0400 Received: from localhost.localdomain (c-24-4-125-7.hsd1.ca.comcast.net [24.4.125.7]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id DBF33D58; Thu, 12 Jul 2018 22:45:53 +0000 (UTC) Date: Thu, 12 Jul 2018 15:45:52 -0700 From: Andrew Morton To: Pavel Tatashin Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com, mhocko@suse.com, linux-mm@kvack.org, dan.j.williams@intel.com, jack@suse.cz, jglisse@redhat.com, jrdr.linux@gmail.com, bhe@redhat.com, gregkh@linuxfoundation.org, vbabka@suse.cz, richard.weiyang@gmail.com, dave.hansen@intel.com, rientjes@google.com, mingo@kernel.org, osalvador@techadventures.net, abdhalee@linux.vnet.ibm.com, mpe@ellerman.id.au Subject: Re: [PATCH v5 1/5] mm/sparse: abstract sparse buffer allocations Message-Id: <20180712154552.db99d1893bcba7f9503534a0@linux-foundation.org> In-Reply-To: <20180712203730.8703-2-pasha.tatashin@oracle.com> References: <20180712203730.8703-1-pasha.tatashin@oracle.com> <20180712203730.8703-2-pasha.tatashin@oracle.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 12 Jul 2018 16:37:26 -0400 Pavel Tatashin wrote: > When struct pages are allocated for sparse-vmemmap VA layout, we first > try to allocate one large buffer, and than if that fails allocate struct > pages for each section as we go. > > The code that allocates buffer is uses global variables and is spread > across several call sites. > > Cleanup the code by introducing three functions to handle the global > buffer: > > sparse_buffer_init() initialize the buffer > sparse_buffer_fini() free the remaining part of the buffer > sparse_buffer_alloc() alloc from the buffer, and if buffer is empty > return NULL > > Define these functions in sparse.c instead of sparse-vmemmap.c because > later we will use them for non-vmemmap sparse allocations as well. > > ... > > +void * __meminit sparse_buffer_alloc(unsigned long size) > +{ > + void *ptr = NULL; > + > + if (sparsemap_buf) { > + ptr = (void *)ALIGN((unsigned long)sparsemap_buf, size); > + if (ptr + size > sparsemap_buf_end) > + ptr = NULL; > + else > + sparsemap_buf = ptr + size; > + } > + return ptr; > +} tweak... diff -puN mm/sparse.c~mm-sparse-abstract-sparse-buffer-allocations-fix mm/sparse.c --- a/mm/sparse.c~mm-sparse-abstract-sparse-buffer-allocations-fix +++ a/mm/sparse.c @@ -491,7 +491,7 @@ void * __meminit sparse_buffer_alloc(uns void *ptr = NULL; if (sparsemap_buf) { - ptr = (void *)ALIGN((unsigned long)sparsemap_buf, size); + ptr = PTR_ALIGN(sparsemap_buf, size); if (ptr + size > sparsemap_buf_end) ptr = NULL; else