Received: by 10.213.65.68 with SMTP id h4csp399278imn; Sat, 7 Apr 2018 00:58:57 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/TFzB/YnCvSzJDdMZLrpLe3f//pu0T5zRWCdftlr7gZswXZR22kU5Ot/t2fDMEqlrWINHI X-Received: by 2002:a17:902:20ca:: with SMTP id v10-v6mr31086728plg.9.1523087937478; Sat, 07 Apr 2018 00:58:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523087937; cv=none; d=google.com; s=arc-20160816; b=iCcKDvlUi/daCXJCigcwfjAsTSXPPo6p+DJQTfFoEcBX3OFnfKd4vJk//J7HulZJB0 fn6WQYtu6igrLrl2lj7mKpo2Vof+U/52UPGXIeKeR+l78MZBZiPjqDwMt5y+fpWIk8Qu ftUXEg2p+nbk2FArGIKvZXobKkM7oqiYwLjQuPEhIHI5ob+hVp0AtXCQ0QV1orH+JK1z 0mmlnhgBqiTzglHVMIQKmn/3F5S02kNDMrQci0pnvHOvavjks8c6OYS2a5zZMu7XpSBT 1mX/xVJXhB5a2uyCAU6JNSYNvNidOaTwTcraZz1QGYzUrrRtRf486F8yVtk6IoXXinxe 494Q== 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:references:to:from:subject:arc-authentication-results; bh=y1BlNxPQrAQr3talDbAeSTgAGhq/+C4moXASe5y04aA=; b=0iM/7lgjwfLuE5/JJj5nLhbY+i95L0VDek42ceGSMr7T+dQpiLFhV+Ly2AF/Gs3XKq Z0f0yCHq2Ap6z+J4IJYMPZsVZi9h5wwElUVFmk+l5Jmca8NzJ4WKGXkgW7CYunD0s+0f 7qT14TbC6UzkFoFs3LtUCayBbi+MRAGhIw8uK3T/taoVRD0g643UGbti2DISLUJ9edur aNSJEUAwRtdK84+dD32037Nhx4jYtmnwSLKNrFtdkdkoRjH3Pi6T/Ogez58NHm0oZ5WH abIljEV4213cYXfhS7ZBafEg90N78hDM+rLa6AfR7uAcHFyx48vWK8nPwgjJ7MOojSbB cuLg== 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 t3si8122800pgp.194.2018.04.07.00.58.20; Sat, 07 Apr 2018 00:58:57 -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 S1751308AbeDGHy4 (ORCPT + 99 others); Sat, 7 Apr 2018 03:54:56 -0400 Received: from mga12.intel.com ([192.55.52.136]:6311 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751031AbeDGHyz (ORCPT ); Sat, 7 Apr 2018 03:54:55 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2018 00:54:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,418,1517904000"; d="scan'208";a="31746042" Received: from haiyuewa-mobl1.ccr.corp.intel.com (HELO [10.255.31.38]) ([10.255.31.38]) by orsmga008.jf.intel.com with ESMTP; 07 Apr 2018 00:54:53 -0700 Subject: Re: [PATCH ipmi/kcs_bmc v1] ipmi: kcs_bmc: optimize the data buffers allocation From: "Wang, Haiyue" 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> Message-ID: <1710edd4-277b-1d2e-5885-a070751ddd2a@linux.intel.com> Date: Sat, 7 Apr 2018 15:54:53 +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 Hi Corey, Since IPMI 2.0 just defined minimum, no maximum: ---- KCS/SMIC Input : Required: 40 bytes IPMI Message, minimum KCS/SMIC Output : Required: 38 bytes IPMI Message, minimum ---- We can enlarge the block size for avoiding waste, and make our driver support most worst message size case. And I think this patch make checking simple (from 3 to 1), and the code clean, this is the biggest reason I want to change. The TLB is just memory management study from book, no data to support access improvement. :) BR, Haiyue On 2018-04-07 10:37, Wang, Haiyue wrote: > > > 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); >> >> >