Received: by 10.213.65.68 with SMTP id h4csp209785imn; Fri, 6 Apr 2018 19:43:01 -0700 (PDT) X-Google-Smtp-Source: AIpwx49t7hoy4JoqdcPdoWkURQJhEahQq6XpngRD3EFLRiBRXGV/ah8JZdjkH9c8G6bfxDtnKZ5r X-Received: by 2002:a17:902:566:: with SMTP id 93-v6mr28818099plf.327.1523068981478; Fri, 06 Apr 2018 19:43:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523068981; cv=none; d=google.com; s=arc-20160816; b=Xi9Ej3AhM/KzFmVmfSHsbnr9G2OFl9OdC4XS7+5p7XFnjhAKaIjddq0MJiC5YNhWuS A7bQ3zBfv5h/KAklzrY2irpU5gbbLKNhxfPoHjXrIMS7q2fSnIcLmHSY9JgTWaQji3CM zhKTrYSgcXNXrw14A2cv0sipX4/NfVq5AElVJ7a07pTmDw1kDy4X5o3tlD9kWLBTZ7uD 4H5g2XK6FMbBfNHLYmrdpFO4A5O3Xpdu4Zsuu9TYYUN8//M1qRBA7C8fds9oof31VJuh 8Wkal8caCR9zKnu8d8Qo/FruOlBnVJv9OwsdVpVtTuvspOpOabWvg4ZyMTaITPkbRQim RO1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=IqQc7jKEd1ID5fXZTkIQFPhWJQ5LVR52d/Z+sUtufLU=; b=ii+EJhLpMxGsvcVTE0VSkhO320VZ+dw+r8rsPUDTKFjj78cyNGOiTLxCen/QOAVw26 fdOFiE0x2I9CeKBXmwQqPfBnvFK9PTO7JzYPFh3lQOhcGuj4ZgKw+aI01pVX5t9Er+34 /m+jmacdB/zO4VXihlCT+B7G0mA58llJ6N8pbL81aoLs+uOOpjk8uNi4JXz5ecUZZbVB YqV1qWDFGJ9g82JG2/qQc65pz3tJiZBGJPJhpwwZXHycc4DAhZKzLo7SNHUO2iI/WuEZ GQ82z2UmmVV5E67mP4PQg2AD+3IjGqbmoS7+uDwX9MPCuBcGhy0npClZAsddElg2s+l/ TVKg== 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 s15-v6si10845333plj.701.2018.04.06.19.41.55; Fri, 06 Apr 2018 19:43:01 -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 S1752079AbeDGChZ (ORCPT + 99 others); Fri, 6 Apr 2018 22:37:25 -0400 Received: from mga04.intel.com ([192.55.52.120]:23401 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751949AbeDGChY (ORCPT ); Fri, 6 Apr 2018 22:37:24 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 19:37:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,417,1517904000"; d="scan'208";a="30792568" Received: from haiyuewa-mobl1.ccr.corp.intel.com (HELO [10.255.24.166]) ([10.255.24.166]) by fmsmga008.fm.intel.com with ESMTP; 06 Apr 2018 19:37:23 -0700 Subject: Re: [PATCH ipmi/kcs_bmc v1] ipmi: kcs_bmc: optimize the data buffers allocation To: minyard@acm.org, openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <1521116452-4993-1-git-send-email-haiyue.wang@linux.intel.com> From: "Wang, Haiyue" Message-ID: Date: Sat, 7 Apr 2018 10:37:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-07 05:47, Corey Minyard wrote: > On 03/15/2018 07:20 AM, Haiyue Wang wrote: >> Allocate a continuous memory block for the three KCS data buffers with >> related index assignment. > > I'm finally getting to this. > > Is there a reason you want to do this?  In general, it's better to not > try to > outsmart your base system.  Depending on the memory allocator, in this > case, you might actually use more memory.  You probably won't use any > less. > I got this idea from another code review, but that patch allocates 30 more the same size memory block, reducing the devm_kmalloc call will be better. For KCS only have 3, may be the key point is memory waste. > In the original case, you allocate three 1000 byte buffers, resulting > in 3 > 1024 byte slab allocated. > > In the changed case, you will allocate a 3000 byte buffer, resulting in > a single 4096 byte slab allocation, wasting 1024 more bytes of memory. > As the kcs has memory copy between in/out/kbuffer, put them in the same page will be better ? Such as the same TLB ? (Well, I just got this from book, no real experience of memory accessing performance. And also, I was told that using space to save the time. :-)). Just my stupid thinking. I'm OK to drop this patch if it doesn't help with performance, or something else. BR. Haiyue > -corey > >> Signed-off-by: Haiyue Wang >> --- >>   drivers/char/ipmi/kcs_bmc.c | 10 ++++++---- >>   1 file changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c >> index fbfc05e..dc19c0d 100644 >> --- a/drivers/char/ipmi/kcs_bmc.c >> +++ b/drivers/char/ipmi/kcs_bmc.c >> @@ -435,6 +435,7 @@ static const struct file_operations kcs_bmc_fops = { >>   struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, >> u32 channel) >>   { >>       struct kcs_bmc *kcs_bmc; >> +    void *buf; >>         kcs_bmc = devm_kzalloc(dev, sizeof(*kcs_bmc) + sizeof_priv, >> GFP_KERNEL); >>       if (!kcs_bmc) >> @@ -448,11 +449,12 @@ struct kcs_bmc *kcs_bmc_alloc(struct device >> *dev, int sizeof_priv, u32 channel) >>       mutex_init(&kcs_bmc->mutex); >>       init_waitqueue_head(&kcs_bmc->queue); >>   -    kcs_bmc->data_in = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL); >> -    kcs_bmc->data_out = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL); >> -    kcs_bmc->kbuffer = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL); >> -    if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer) >> +    buf = devm_kmalloc_array(dev, 3, KCS_MSG_BUFSIZ, GFP_KERNEL); >> +    if (!buf) >>           return NULL; >> +    kcs_bmc->data_in  = buf; >> +    kcs_bmc->data_out = buf + KCS_MSG_BUFSIZ; >> +    kcs_bmc->kbuffer  = buf + KCS_MSG_BUFSIZ * 2; >>         kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR; >>       kcs_bmc->miscdev.name = dev_name(dev); > >