From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06B61C2BA2B for ; Fri, 17 Apr 2020 03:24:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BC9AA21D94 for ; Fri, 17 Apr 2020 03:24:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="U55S4Mjk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC9AA21D94 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4DFA88E0003; Thu, 16 Apr 2020 23:24:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48FB08E0001; Thu, 16 Apr 2020 23:24:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A5C28E0003; Thu, 16 Apr 2020 23:24:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1B8B38E0001 for ; Thu, 16 Apr 2020 23:24:10 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CB2054DBE for ; Fri, 17 Apr 2020 03:24:09 +0000 (UTC) X-FDA: 76715903418.25.feast84_7b5bb5e890110 X-HE-Tag: feast84_7b5bb5e890110 X-Filterd-Recvd-Size: 2786 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Apr 2020 03:24:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4NwRdnd1tqHPknUqRG8dZUJNk1TYuEB6jMxKNZTYnKQ=; b=U55S4Mjk3H/DrgX1Nyk3DwecPx 3RJmjnZtDd66aTMXfWjADMplV3gkjopia000iB+pHjew3iT1rNXZVQRbZYX/wv1l56w7iL2V9c6qV RYUOD5NdhycZ5NQco7Bk7Kxhry9iDWjfeKVlIfI27M9d7tnwIUmN9tfwTn5Dr2yxoV5ZH6FwmCPTf ezxvyAxZslVYOgzG+zDCxiAIMDQrmZM6H4ZMI3y3xaPLmqjUqqEj8PI8ELcj8PziQXA0lX0HgFrY8 oOQF3pROJzkMuGePVojzUOJaSE3G/44BKEpWlh2FflNnAviNSZWvE1tWdlOm6RgwBkvEbA15YkeCq sP7+/9qA==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jPHbe-0005WU-5o; Fri, 17 Apr 2020 03:23:54 +0000 Date: Thu, 16 Apr 2020 20:23:54 -0700 From: Matthew Wilcox To: Bernard Zhao Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@vivo.com Subject: Re: [PATCH] kmalloc_index optimization(code size & runtime stable) Message-ID: <20200417032354.GK5820@bombadil.infradead.org> References: <1587089010-110083-1-git-send-email-bernard@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1587089010-110083-1-git-send-email-bernard@vivo.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 16, 2020 at 07:03:30PM -0700, Bernard Zhao wrote: > kmalloc_index inline function code size optimization and runtime > performance stability optimization. After optimization, the function > kmalloc_index is more stable, the size will never affecte the function`s > execution efficiency. > And follow test data shows that the performance of new optimization > exceeds the original algorithm when applying for more than 512 Bytes > (include 512B).And new optimization runtime is more stable than before. That's all very well and good, but the vast majority of allocations are less than 512 bytes in size! Your numbers show that on average, this patch makes the kernel slower! > size time/Per 100 million times > old fun new fun with optimise > 8 203777 241934 > 16 245611 409278 > 32 236384 408419 > 64 275499 447732 > 128 354909 416439 > 256 360472 406598 > 512 431072 409168 > 1024 463822 407401