Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp96489img; Thu, 21 Mar 2019 15:02:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqzdC6a32ZmFZ/wE8gzjfwkBHv/IWaW5RGNO1Vkxh1KBJdmmbaGRlJKFwJM1c7Fp9GRdLNVe X-Received: by 2002:a62:a10c:: with SMTP id b12mr5582848pff.234.1553205764108; Thu, 21 Mar 2019 15:02:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553205764; cv=none; d=google.com; s=arc-20160816; b=YzLiqbEVZadLcR1wfDDfnWoZYGAlu6PD2hQjkvoXLciieGwIc5nZJK/IaOtTZDrPgy FiIPFLBZX/9n6Oj5f7UyN80Le2hFij/oBih1Qm610Zj/XFWtPFBXJXl0QuYO1tDVvgHh WmLkiTBwZohUK9q1O58IkxrK+foy8SC+QdT9wV8D6jE/7tlkTdaNUqU1NUNeEfaNWvo0 FIlwfN0nTLpYsgINHKHlA9cGQlJ0/ZombJBKkZEDJAan6ymt1iAp+H6vCD4n4/je3aB3 t80S6qBR8az58Tv1nn92AJnq+Kg1dIb2p9cXdRIlBEmWw+R7/Hn1fPOCeooVKGNhsvUs cwxw== 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; bh=75wXbI6fqRaqYr1j6d3FptNQOdk6OKV3h4rajfKqpEk=; b=tZpVBC0G5J3jrz115WOCFwKQZ0sdURshkmEUNGT0jBrYsSwI0doK2OQVNBfDpMsunf HaGXqfdPfUyNaLF6pm++btv+Jf6YJT//M/9QASYEP5dzm7bIUMHP7QwhFrR4TbMTwxeO cEnh0fBhh2eJctcAWc9aIFWCycWp70AvVA5xmuTGECForUZUUq8osEyMKsqFyl6VR/uj 2LPEoHMvGJ0BDFPvUB4cbBH40bRYUOqUMvfLBklTZOclUSfUyp/rcDRRUh7TUkMmsgSD vMIS1zMZQvqEgk8Li4WXK9kn31Fc8jOXxjzta3uNHlzZxAyj3rtW58SEZWbr2btMM8mZ S8JQ== 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 q10si5192136plr.347.2019.03.21.15.02.26; Thu, 21 Mar 2019 15:02: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 S1727519AbfCUWBL (ORCPT + 99 others); Thu, 21 Mar 2019 18:01:11 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:54010 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727210AbfCUWBJ (ORCPT ); Thu, 21 Mar 2019 18:01:09 -0400 Received: from localhost.localdomain (c-73-223-200-170.hsd1.ca.comcast.net [73.223.200.170]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 9F11EEF1; Thu, 21 Mar 2019 22:01:07 +0000 (UTC) Date: Thu, 21 Mar 2019 15:01:06 -0700 From: Andrew Morton To: "Uladzislau Rezki (Sony)" Cc: Michal Hocko , Matthew Wilcox , linux-mm@kvack.org, LKML , Thomas Garnier , Oleksiy Avramchenko , Steven Rostedt , Joel Fernandes , Thomas Gleixner , Ingo Molnar , Tejun Heo Subject: Re: [RFC PATCH v2 0/1] improve vmap allocation Message-Id: <20190321150106.198f70e1e949e2cb8cc06f1c@linux-foundation.org> In-Reply-To: <20190321190327.11813-1-urezki@gmail.com> References: <20190321190327.11813-1-urezki@gmail.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, 21 Mar 2019 20:03:26 +0100 "Uladzislau Rezki (Sony)" wrote: > Hello. > > This is the v2 of the https://lkml.org/lkml/2018/10/19/786 rework. Instead of > referring you to that link, i will go through it again describing the improved > allocation method and provide changes between v1 and v2 in the end. > > ... > > Performance analysis > -------------------- Impressive numbers. But this is presumably a worst-case microbenchmark. Are you able to describe the benefits which are observed in some real-world workload which someone cares about? It's a lot of new code. I t looks decent and I'll toss it in there for further testing. Hopefully someone will be able to find the time for a detailed review. Trivial point: the code uses "inline" a lot. Nowadays gcc cheerfully ignores that and does its own thing. You might want to look at the effects of simply deleting all that. Is the generated code better or worse or the same? If something really needs to be inlined then use __always_inline, preferably with a comment explaining why it is there.