From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751050AbdAXMKn (ORCPT ); Tue, 24 Jan 2017 07:10:43 -0500 Received: from mout.web.de ([212.227.17.12]:57157 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751014AbdAXMKl (ORCPT ); Tue, 24 Jan 2017 07:10:41 -0500 Subject: Re: KVM: s390: Move two error code assignments in kvm_vm_ioctl_get_dirty_log() To: =?UTF-8?Q?Christian_Borntr=c3=a4ger?= , kvm@vger.kernel.org, linux-s390@vger.kernel.org References: <70f41e59-d8a4-de42-6064-80ecf6acc065@users.sourceforge.net> <35411200-2bd6-1c65-7d7f-21a6353875ea@de.ibm.com> <01d581bb-9db6-cba1-e476-49c814c3ebf0@users.sourceforge.net> <50ae2ba4-572d-8524-fc31-acc1a8d1ad99@de.ibm.com> Cc: Cornelia Huck , Heiko Carstens , Martin Schwidefsky , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , LKML , kernel-janitors@vger.kernel.org From: SF Markus Elfring Message-ID: <75c6315c-8947-2816-64da-947f6a29ac57@users.sourceforge.net> Date: Tue, 24 Jan 2017 13:10:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <50ae2ba4-572d-8524-fc31-acc1a8d1ad99@de.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:T3HhhLTZgSRF33QX80K/hE0LCePIXu+xNiu0UtSPrR+RbMZx89G NHk19zxqALYxpBticfi5NFPPjPDKT405LV/aSni4GWqZQ3bDXETIn3gyneocaPlRCcr2Ph3 7UJ9Az++MvcetuRWYixI7QotYLUWo5oW4ZzcWOI80QjPI7D31BVBnZKqAZ93kFyoY2ea3yY 8J7h+2t0XV3i3Cbm9remg== X-UI-Out-Filterresults: notjunk:1;V01:K0:bU7J7T/esns=:ho7C9qWzQoAr0ZJ43nMkBz 9eKb7//y/SIWXzdYJ1NO/as3SxTHIzzOTRrM4v/doRwlKnd7obPB00WlQ7/yHp9JstptrVqyw 1k1y5dZ8jC/Ij7NJhkwey3YZTz+KNS585nrq6v1Pyd30PBlPZhUsDe382piPGY+fuuR8SdN+B rEK+k7xzNmOVYcSTjZU7Z0mAJF40kcbA8M9iW5nVP+jY8cWb5kS+UoPOi1USikTndn3hy1xmc 1fFvEA4rlHsw0JJ5veckOVcfEVdSG393F+IVAJlQX7ly9CEjZsmRGIA/KjruXRLxBZsAFnMP/ qQqH1dsvRmqqME7Ozp/gHjZPQVhNAi4Faqto3wAGWn/QJ8wQkq4KWhNVjcc0WkM/V+Jnn9Gin SE9BoAAwvYKLLO+QhKEFJUQOhWD/x2vkEC9brYlMRF1a5sX6KUIRrSPsrC9Kq7RXt6E8E4Mf2 8D+sHtvtG9OH+/OUOJrHcp5LqiIRh2sPnetu8odhtaJpICPx0atOV+YrVIoaWfzpzgwgWpsCF YWmTi/yxAGo28YYPLIBGN1oghc8JIrEdDDGR8sVFEuhDhDWxCDAC5jLiarI2IopylhczFdlk6 7lhACpJbeYDhbPYsSV+lLPLY7YRp6KFhzCTZkCbUpe1NAiyskTIhoBDSYGsWPiBCRNHa5qawu KpTi7S0yg0578Dy18VLoeKSIshDKaDdu79pDP/MQIP9lnizXVc21F8pJEpEPZGx7N2p16Ki3C cg59voea9Y8uTTzlARiS/OU5BPddzx3We/zioTyipRUi6R7YzvvcRACAGpgYa8HP4z9HbPGJX pU4LPQq Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> Would you like to check run time consequences >> for the shown error code settings once more? > > Sure, lets for now ignore the fact that the performance of an error path > does not matter most of the time. I am concerned that extra error code settings within the “success path” could influence the run time behaviour in unwanted ways. > After tree building and optimization your change should not matter at all > regarding performance for a decent compiler. I find your optimism interesting. > The compiler can and will do much more complex transformations than this. This technology is often fine. > Since you have send several patches that trigger compile time warnings or > errors, let me do this exercise for you and let us check what your patch > changes in terms of run time consequences. > > > $ git checkout v4.10-rc4 > HEAD is now at 49def18... Linux 4.10-rc4 > > $ make arch/s390/kvm/kvm-s390.o > [..] Thanks for your build demonstration. > $ objdump -d arch/s390/kvm/kvm-s390.o | md5sum > 55c1e081f55cef90b3ffcc06a13721c1 - > > $ git am ~/code/elfring/[PATCH] KVM: s390: Move two error code assignments in kvm_vm_ioctl_get_dirty_log().eml > Applying: KVM: s390: Move two error code assignments in kvm_vm_ioctl_get_dirty_log() > > $ make arch/s390/kvm/kvm-s390.o > [..] > > $ objdump -d arch/s390/kvm/kvm-s390.o | md5sum > 55c1e081f55cef90b3ffcc06a13721c1 - > > As you can see the binary is identical, The hashes became the same with the selected tool. > so I can make an educated guess, that there is no performance improvement > due to your patch. How much does such a software generation result fit really to expectations? Should the two shown implementation variants for a function like "kvm_vm_ioctl_get_dirty_log" usually lead to different object code files? Regards, Markus