Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758418AbcJQIMX (ORCPT ); Mon, 17 Oct 2016 04:12:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:48512 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758333AbcJQILI (ORCPT ); Mon, 17 Oct 2016 04:11:08 -0400 Subject: Re: MD-RAID: Use seq_putc() in three status functions? To: SF Markus Elfring References: <566ABCD9.1060404@users.sourceforge.net> <786843ef-4b6f-eb04-7326-2f6f5b408826@users.sourceforge.net> <92c52f1d-d151-cea6-e9ac-31378e6862d0@users.sourceforge.net> <1475771699.1914.10.camel@perches.com> <77fb6fdc-7480-8607-0af1-42f73c125b9d@users.sourceforge.net> <688764a4-072d-2faf-37ba-a222b190a5d9@suse.de> <59d71170-c48d-a084-c748-b6ab74a2bee4@users.sourceforge.net> <1e151094-e228-5307-ae2f-b376b31f5628@suse.de> <83e720c6-9037-a3c1-6e83-27505805f37f@users.sourceforge.net> Cc: linux-raid@vger.kernel.org, Christoph Hellwig , Guoqing Jiang , Jens Axboe , Joe Perches , Mike Christie , Neil Brown , Shaohua Li , Tomasz Majchrzak , LKML , kernel-janitors@vger.kernel.org From: Hannes Reinecke Message-ID: <2cc42b2f-1f1a-e95c-91fa-54e1dd3b6d49@suse.de> Date: Mon, 17 Oct 2016 10:09:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <83e720c6-9037-a3c1-6e83-27505805f37f@users.sourceforge.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2270 Lines: 59 On 10/17/2016 09:39 AM, SF Markus Elfring wrote: >>>> Does it improve code? Does it improve anything? >>> >>> Yes. - I got such an impression. >>> >>> * Is it more efficient to call the function "seq_printf" for the desired data processing >>> for a single character than to pass it to the function "" in a string? >>> >>> * Will the required data transfer shrink a bit for the affected functions because of >>> such a change? >>> >> Which are questions _you_ should be able to answer. > > I wonder that the answers are not obvious for you already. > > Calling the function "seq_putc" will be more efficient than "seq_printf" > in this case because of the following reasons. > > 1. How does the distribution look like for supported processor architectures > where the data transfer for bytes (as a function call parameter) > is faster than for (string) pointers? > How would I know? I would assume that _you_ did some measurements here; after all, _you_ are trying to push this patch. I could easily claim that seq_printf() is more efficient than seq_putc(), and won't apply your patch. So _you_ have to prove that your patch is more efficient. > 2. Did anybody measure already how many the execution times can vary > for these functions? > Probably not. But referring to the previous topic: Unless _you_ prove that _your_ patch is more efficient it won't get applied. _You_ want us to apply your patch, so the burden is on _you_ to provide the required data. > Where do you get doubts about its efficiency for the data processing > of a single character? > Because it's being called at the end of a function calling seq_printf() already. So exchanging a single call is probably not helping anything, as the compiler will optimize it anyway. Case in point: with your patch the x86_64 compiler generates nearly identical code for driver/md/raid1.c, but with one instruction _more_ after your patch has been applied. So it's not immediately obvious that your patch is an improvement. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg GF: F. Imend?rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N?rnberg)