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;
From:   Roman Gushchin <guro@fb.com>
To:     Vlastimil Babka <vbabka@suse.cz>
CC:     Roman Gushchin <guroan@gmail.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Matthew Wilcox <willy@infradead.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH 2/3] mm: separate memory allocation and actual work in
 alloc_vmap_area()
Thread-Topic: [PATCH 2/3] mm: separate memory allocation and actual work in
 alloc_vmap_area()
Thread-Index: AQHUzUkHvmEZiK9g+UuhGR24XSYfTqX236aA//+c5QCASiueAIAAYSWA
Date:   Wed, 17 Apr 2019 19:15:41 +0000
Message-ID: <20190417191535.GA16663@tower.DHCP.thefacebook.com>
References: <20190225203037.1317-1-guro@fb.com>
 <20190225203037.1317-3-guro@fb.com>
 <db6b9745-7e64-6eb9-6b2b-da9d157a779b@suse.cz>
 <20190301164834.GA3154@tower.DHCP.thefacebook.com>
 <ed835e2c-9357-c7ea-f458-0cd9b8f6e966@suse.cz>
In-Reply-To: <ed835e2c-9357-c7ea-f458-0cd9b8f6e966@suse.cz>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:200::3:856]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7c66eff2-ce3d-4827-6217-08d6c36914e5
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020);SRVR:BYAPR15MB3510;
x-ms-traffictypediagnostic: BYAPR15MB3510:
x-microsoft-antispam-prvs: <BYAPR15MB3510AE76931D0CB681CE1094BE250@BYAPR15MB3510.namprd15.prod.outlook.com>
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(366004)(396003)(136003)(376002)(346002)(39860400002)(199004)(189003)(478600001)(476003)(46003)(11346002)(446003)(6436002)(71200400001)(6116002)(54906003)(186003)(71190400001)(14454004)(1076003)(486006)(6512007)(33656002)(316002)(53936002)(2906002)(305945005)(6916009)(6246003)(6486002)(4326008)(25786009)(68736007)(53546011)(386003)(5660300002)(7736002)(229853002)(9686003)(6506007)(14444005)(8936002)(256004)(8676002)(81166006)(52116002)(81156014)(99286004)(76176011)(106356001)(86362001)(97736004)(105586002)(102836004)(93886005);DIR:OUT;SFP:1102;SCL:1;SRVR:BYAPR15MB3510;H:BYAPR15MB2631.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: u5AC+a5Vz+MMnt3NWdzfnAlZW4w1U+GfW00UMx27X76ezXhGx9kBu3MBa96lWoTQm/GQhv3oF6T2hieyXOaj5W4m4O4d+I7puN0/7yLphumvyeiE4aIVf4CqaIJ0VJnzZ2yzF6ygi0VHZuVEwF9k7urTA95R4r1NPHNO25w4MgEz3PBcUu3h0+Fy0I9j6+jiDDGHG4XLXY2WkvqEvO5ra6NXB21CLKtJAjUd++L3gic2oDvppIsbCsQMk7JIK4VCn/gYjojiMmO+NwFkfiVl4t6kEPQPx8XAsgXidfQHh7cHleA+JbuaYZ4gY6LjBZmISitXkSLNJAJLnC1KQrG0ZOw03YAt9vUTIvf8WmM2MnB9vhZSRbYnySV2SdMzrCB8FPfaZP3IMipqaAzAhUigOx87jblNMVR1T4jqATyslIQ=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <212D8DE2A7DDF946B1E64CEB54733AEC@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c66eff2-ce3d-4827-6217-08d6c36914e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 19:15:41.2986
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3510
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-17_08:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 17, 2019 at 03:27:56PM +0200, Vlastimil Babka wrote:
> On 3/1/19 5:48 PM, Roman Gushchin wrote:
> > On Fri, Mar 01, 2019 at 03:43:19PM +0100, Vlastimil Babka wrote:
> >> On 2/25/19 9:30 PM, Roman Gushchin wrote:
> >>> alloc_vmap_area() is allocating memory for the vmap_area, and
> >>> performing the actual lookup of the vm area and vmap_area
> >>> initialization.
> >>>
> >>> This prevents us from using a pre-allocated memory for the map_area
> >>> structure, which can be used in some cases to minimize the number
> >>> of required memory allocations.
> >>
> >> Hmm, but that doesn't happen here or in the later patch, right? The on=
ly
> >> caller of init_vmap_area() is alloc_vmap_area(). What am I missing?
> >=20
> > So initially the patch was a part of a bigger patchset, which
> > tried to minimize the number of separate allocations during vmalloc(),
> > e.g. by inlining vm_struct->pages into vm_struct for small areas.
> >=20
> > I temporarily dropped the rest of the patchset for some rework,
> > but decided to leave this patch, because it looks like a nice refactori=
ng
> > in any case, and also it has been already reviewed and acked by Matthew
> > and Johannes.
>=20
> OK then,
>=20
> Acked-by: Vlastimil Babka <vbabka@suse.cz>

Thank you for looking into this and other patches from the series!

Btw, it looks like that recent changes in vmalloc code are in a conflict
with this patch, so I'll drop it for now, and will resend two other as v4.

Thanks!