Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2673264pxk; Sun, 6 Sep 2020 09:08:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywH4kRgQzUw0eqWyIPcX8+9hGu1BysNc4IHWHcHM80DBiB46Ifl7xIRg4ToTacc9SI2wIR X-Received: by 2002:a17:906:18a9:: with SMTP id c9mr16970616ejf.294.1599408482022; Sun, 06 Sep 2020 09:08:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599408482; cv=none; d=google.com; s=arc-20160816; b=b4sALa4/NzDphumgjWhMB7+fRnHB7G8LNDMZwjKrsjcQBhLHYWW6lh/mZ01srMZSP6 r5DKmf8EsGUTwUmd6BvPjVPiwSxCWCX3WOlsnXm9gcexYuUo47vXwk/cvj81zYVxxEOV ajv1ZSXSYKKS688LCqCboqFZfuDWqocm2o8S0Gz+47Rxhilgf4hf7TzPO9fn9NZzvNTO 0Q3sMQCGBDH0d+3HaSF9aU4O0oBLoyeZum5g98W9MDzWmg0j4cNesRiamLRr9tB7xAKd vXXPJxZ8Ywxji8eB1e6uxVdbSh9+dic1eJ108O2ny/WXbvNDqqYv1rScD4tdQCYmABmX C/xA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=BA+i5YGjfQG9eG4FsIBKaO49/ge9c9KPdPWriN/3fOs=; b=dRH/iv9zK4W77AQXmpbx2ybfaFhc7IN4Huyab4BmitufmgBe/wMV76xaGBoWnfh+QC jUN67Dkf9Mcw3EjS5DCmoGCkxF+PH9pjEdZHnJ6ExiZ2x5r5qBdV5LK6LBlCdo5UCWQV QmaRahglBsL+wwwgQ4TPK3fofzwzpQu1oTGVa7sK5WtL9a2x/GMxJQIcIPOL/tE1bIda CM2WGq6xUiWXtMKhBU5lEnFFUpmL+ckEWD5cmG2rEynXNgP9OScjb3koPeSSJFseYqfm OocwGxC6kQiMNRU9sRyT+l1ZZWx6xYvrJXiP4pKSGsc9OD3VLuVvznn8Fs6mET6tKxhe iwnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MVSJlqgI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n8si8186726ejj.649.2020.09.06.09.07.37; Sun, 06 Sep 2020 09:08:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MVSJlqgI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729032AbgIFQGq (ORCPT + 99 others); Sun, 6 Sep 2020 12:06:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726931AbgIFQGo (ORCPT ); Sun, 6 Sep 2020 12:06:44 -0400 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83676C061573 for ; Sun, 6 Sep 2020 09:06:43 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id s205so13299206lja.7 for ; Sun, 06 Sep 2020 09:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BA+i5YGjfQG9eG4FsIBKaO49/ge9c9KPdPWriN/3fOs=; b=MVSJlqgI3vgMTxPFMAOo4i6tZp7umbOnF/kWvF8/51BSRtl3eNXGns3AlI3TFJPyg5 GHo+xx1eScL55ZNik/VOxHI5x3T26obWH11G+Sf4IiooDl3rNNOF//kc9fFnkYBOeyjY pb7xA0rVwc791J5AtkYptA7jwAH2Rndp7+LmEHyvn7kQW+LUOqEpm6X6Das1mIp2Gq2I 4sHDWgEteePirwpeicwVGmIFGUyNBVql12Dy+IIYQiBf8bhIl3SRsi5pfRw61LumlNX9 GwOzRFfBEhWveanqmKZsB06hK9DEaS3wDoPM9Wqc/g5BqtO2Ef7IMDMir+DC35UQVSeL dZew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BA+i5YGjfQG9eG4FsIBKaO49/ge9c9KPdPWriN/3fOs=; b=pziPayD8CcBa4fbZBy6zGe7VqA39Bw+xMHcbfxrswKvU3PhKQAF1xRlN6KZw4mrjIr FMpgQZKIFw0fEXpJvEJysBkO/axfoP7hAfIXnaPUwUzxOyddBgRFJOWe+RDk4hJ2th6j T0s0slEKmTvli63PmT9vNpgE1ktFEWkVsL4JhpP07bAEk3CVzC4t+J0OjXAqHrdeIAOi JexOgaHTYep9ADGXAWOykdfzGBkjcOlrbb+3bgY+Sw//dFxtR1RavvxQmjjFd6HbZrFQ ZijaAhB3fx/EtZYG+r2PmQj4hlz2GKF9C2+BNoSF7QOiYotFzK/yS7ktFsYue7eNx8L5 0LDw== X-Gm-Message-State: AOAM530y9eqWaJ1iFUyXYoS8mbMY2RxIhTdy/HNu9fixF9ttfajdN9K7 yaDYPfwvLTj4qmucJ8odANa8jC6uG8DXXw== X-Received: by 2002:a2e:7a14:: with SMTP id v20mr8832285ljc.429.1599408401709; Sun, 06 Sep 2020 09:06:41 -0700 (PDT) Received: from [192.168.8.100] (188.147.111.252.nat.umts.dynamic.t-mobile.pl. [188.147.111.252]) by smtp.gmail.com with ESMTPSA id m1sm4887507lfr.32.2020.09.06.09.06.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Sep 2020 09:06:41 -0700 (PDT) Subject: Re: [PATCH] mm/mmu_notifier.c: micro-optimization substitute kzalloc with kmalloc To: Mike Rapoport Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org References: <20200906114321.16493-1-mateusznosek0@gmail.com> <20200906142645.GA1976319@kernel.org> From: Mateusz Nosek Message-ID: <39c79454-9a97-2c06-3186-939c1f3a2b27@gmail.com> Date: Sun, 6 Sep 2020 18:06:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200906142645.GA1976319@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I performed simple benchmarks using custom kernel module with the code fragment in question 'copy-pasted' in there in both versions. In case of 1k, 10k and 100k iterations the average time for kzalloc version was 5.1 and for kmalloc 3.9, for each iterations number. The time was measured using 'ktime_get(void)' function and the results given here are in ktime_t units. The machine I use has 4 core Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz CPU. The performance increase happens, but as you wrote it is probably not really noticeable. I have found 3 other places in kernel code with similar kzalloc related issues, none of which seems to be 'hot' code. I leave the decision if this patch and potential others I would send regarding this issue, are worth applying to the community and maintainers. Best regards, Mateusz Nosek On 9/6/2020 4:26 PM, Mike Rapoport wrote: > Hi, > > On Sun, Sep 06, 2020 at 01:43:21PM +0200, mateusznosek0@gmail.com wrote: >> From: Mateusz Nosek >> >> Most fields in struct pointed by 'subscriptions' are initialized explicitly >> after the allocation. By changing kzalloc to kmalloc the call to memset >> is avoided. As the only new code consists of 2 simple memory accesses, >> the performance is increased. > > Is there a measurable performance increase? > > The __mmu_notifier_register() is not used that frequently to trade off > robustness of kzalloc() for slight (if visible at all) performance gain. > >> Signed-off-by: Mateusz Nosek >> --- >> mm/mmu_notifier.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c >> index 4fc918163dd3..190e198dc5be 100644 >> --- a/mm/mmu_notifier.c >> +++ b/mm/mmu_notifier.c >> @@ -625,7 +625,7 @@ int __mmu_notifier_register(struct mmu_notifier *subscription, >> * know that mm->notifier_subscriptions can't change while we >> * hold the write side of the mmap_lock. >> */ >> - subscriptions = kzalloc( >> + subscriptions = kmalloc( >> sizeof(struct mmu_notifier_subscriptions), GFP_KERNEL); >> if (!subscriptions) >> return -ENOMEM; >> @@ -636,6 +636,8 @@ int __mmu_notifier_register(struct mmu_notifier *subscription, >> subscriptions->itree = RB_ROOT_CACHED; >> init_waitqueue_head(&subscriptions->wq); >> INIT_HLIST_HEAD(&subscriptions->deferred_list); >> + subscriptions->active_invalidate_ranges = 0; >> + subscriptions->has_itree = false; >> } >> >> ret = mm_take_all_locks(mm); >> -- >> 2.20.1 >> >> >