Message ID | 20230202151736.64552-1-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp302196wrn; Thu, 2 Feb 2023 07:25:52 -0800 (PST) X-Google-Smtp-Source: AK7set+iH1WZQjdCCVOIEiYsT5bXdLN13i0wElJ2ZxbDL4xghnaf0lVt0qPfnhP44wJFtd3Su0Si X-Received: by 2002:a17:906:f52:b0:88c:e5ce:e13e with SMTP id h18-20020a1709060f5200b0088ce5cee13emr6698290ejj.33.1675351552046; Thu, 02 Feb 2023 07:25:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675351552; cv=none; d=google.com; s=arc-20160816; b=sEtqtobrLSRxByFj2/T/XTLYit3JPwIS45jFiKImHKHuSMJPrrTegX+a4Hv2HvSUO9 uH7nPQhb4feg0CUn4UAizONj13dyuGUD8tRbgZiiQqXnuNgOfx4KNQMZeNjdzATmTc8G VTE/qJsioKmBUONnU0uxK55NhK818UJ1TcLL1wIxODkeWQ2OOLxPJV9hH9vLZxI0bJ2+ EPg3h/YqxbWkATTMYI2RW2oftIu3Zrb3gkIzmQyauVDQLw1O9zASfc9r4/ViYV4FIaWd dUSvSaHHH6Ji36Dn5ru/mqc7VlMl1nXfxzUfwhN2+3ZG4fUZKDaqzaapZVfYXH7d8Gdj fD1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from:dkim-signature; bh=q6vpo+egjJtkpRWH9wswlLLdColGDwIHSEkQgxo4gks=; b=OkpnpPfSCKe5CEuPh2S0od1R2ltrYaBwgDK6GfNNsTTtRQcCEzgp+xPDtjhqUeRLX4 5ue9oRxtWlVv2nvV4kGobLVX7esfGxtqdmz9FNGef2euo7kDMYaDWS5GE3FcRAUXzhMO OGYQFfCHBTA+Ng/3SawurovH5xvBKDbTpEIl1EDGc8Lm9d5zwOhR8kuNXNIVZspFId21 NAoA7Q+tPOtVNf4bSjpeFezIrfv8mePFpFX88RmBZ7uh8j3UZyMujrPdy41KhlC+MW0C IeT3kPe1onP7m98lxKw9Y9Iz7EecDat+pvHNWYG0ldSR/+xqVWklHHXf1TOFHa4YiwAc DPWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PkldrLm6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fm21-20020a1709072ad500b0087bdb285586si19945577ejc.45.2023.02.02.07.25.26; Thu, 02 Feb 2023 07:25:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PkldrLm6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232716AbjBBPTY (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Thu, 2 Feb 2023 10:19:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232793AbjBBPTL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Feb 2023 10:19:11 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD12692C25; Thu, 2 Feb 2023 07:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675351136; x=1706887136; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=XPtZMEGcQAaazFq43vly0rUfFz9SXA0R2yb5TWeDZj8=; b=PkldrLm6Ldlvjg37oi3xmPcjtkYWkVUqQvnvQbOeaAv0EgGCtonUQHUg D2z7v6RbXSbJLT1ZxfUVv37Ump3E2GRAyqPmbkyYbDB6wI6KHwBEu5nL7 fmUh8FGjdbAaJrAynyjMh24hnMZMSmZxQzM2LHrhCZ2Niw7SoSSvdVZt0 YnBf81s1EcoRh5ULwF5Tlv/7LTiYhL2k0K3de7/LSQURMgvxjIiz69AyW aA6oUv+LRENCY0GOHleHufkQxlMZeVFw8zzrtFAlxfmZCiSVA/ek4viP/ x+X6RNMpYiNURLGMpz/9Jq9VCoAoUsCSSKKBc9/epl2xmWiiKmkXb3auq Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10608"; a="355811919" X-IronPort-AV: E=Sophos;i="5.97,267,1669104000"; d="scan'208";a="355811919" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Feb 2023 07:17:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10608"; a="665320924" X-IronPort-AV: E=Sophos;i="5.97,267,1669104000"; d="scan'208";a="665320924" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga002.jf.intel.com with ESMTP; 02 Feb 2023 07:17:10 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id C5E0D332; Thu, 2 Feb 2023 17:17:47 +0200 (EET) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, =?utf-8?b?SsOzIMOBZ2ls?= =?utf-8?b?YSBCaXRzY2g=?= <jgilab@gmail.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v1 1/1] usb: gadget: configfs: Use memcpy_and_pad() Date: Thu, 2 Feb 2023 17:17:36 +0200 Message-Id: <20230202151736.64552-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756733429080357458?= X-GMAIL-MSGID: =?utf-8?q?1756733429080357458?= |
Series |
[v1,1/1] usb: gadget: configfs: Use memcpy_and_pad()
|
|
Commit Message
Andy Shevchenko
Feb. 2, 2023, 3:17 p.m. UTC
Instead of zeroing some memory and then copying data in part or all of it,
use memcpy_and_pad().
This avoids writing some memory twice and should save a few cycles.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/usb/gadget/configfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
From: Andy Shevchenko > Sent: 02 February 2023 15:18 > > Instead of zeroing some memory and then copying data in part or all of it, > use memcpy_and_pad(). > This avoids writing some memory twice and should save a few cycles. Maybe, maybe not. It rather depends on the lengths involved (the code doesn't seem to be in the main tree). The cost of the conditionals and the misaligned length/start for the memset() could easily overwhelm any apparent saving. A memset() of a constant whole number of words is going to be significantly faster than the partial one. David > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > drivers/usb/gadget/configfs.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c > index 1346b330b358..0ee47e4c22cb 100644 > --- a/drivers/usb/gadget/configfs.c > +++ b/drivers/usb/gadget/configfs.c > @@ -909,8 +909,7 @@ static ssize_t webusb_landingPage_store(struct config_item *item, const char *pa > > mutex_lock(&gi->lock); > // ensure 0 bytes are set, in case the new landing page is shorter then the old one. > - memset(gi->landing_page, 0, sizeof(gi->landing_page)); > - memcpy(gi->landing_page, page, l); > + memcpy_and_pad(gi->landing_page, sizeof(gi->landing_page), page, l, 0); > mutex_unlock(&gi->lock); > > return len; > -- > 2.39.1 - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Thu, Feb 02, 2023 at 10:21:09PM +0000, David Laight wrote: > From: Andy Shevchenko > > Sent: 02 February 2023 15:18 > > > > Instead of zeroing some memory and then copying data in part or all of it, > > use memcpy_and_pad(). > > This avoids writing some memory twice and should save a few cycles. > > Maybe, maybe not. > It rather depends on the lengths involved (the code doesn't seem to be in the > main tree). > > The cost of the conditionals and the misaligned length/start for the > memset() could easily overwhelm any apparent saving. > > A memset() of a constant whole number of words is going to be significantly > faster than the partial one. Then you can put some (little I suppose) efforts in optimizing memcpy_and_pad() once for all, no?
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c index 1346b330b358..0ee47e4c22cb 100644 --- a/drivers/usb/gadget/configfs.c +++ b/drivers/usb/gadget/configfs.c @@ -909,8 +909,7 @@ static ssize_t webusb_landingPage_store(struct config_item *item, const char *pa mutex_lock(&gi->lock); // ensure 0 bytes are set, in case the new landing page is shorter then the old one. - memset(gi->landing_page, 0, sizeof(gi->landing_page)); - memcpy(gi->landing_page, page, l); + memcpy_and_pad(gi->landing_page, sizeof(gi->landing_page), page, l, 0); mutex_unlock(&gi->lock); return len;