From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752488AbcIDFqV (ORCPT ); Sun, 4 Sep 2016 01:46:21 -0400 Received: from mout.web.de ([217.72.192.78]:61998 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbcIDFqT (ORCPT ); Sun, 4 Sep 2016 01:46:19 -0400 Subject: Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile() To: Julian Calaby References: <566ABCD9.1060404@users.sourceforge.net> <2179bf7c-9878-adf7-da97-2746d5aa3d34@users.sourceforge.net> Cc: sparclinux , Adam Buchbinder , Alexei Starovoitov , Daniel Borkmann , "David S. Miller" , Rabin Vincent , LKML , kernel-janitors , Julia Lawall , Paolo Bonzini From: SF Markus Elfring Message-ID: <1af7e987-0233-f972-6c00-6d5e00898188@users.sourceforge.net> Date: Sun, 4 Sep 2016 07:45:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:osJv1I9LkggvdfJM5zprCy39Gs8tff73XsbBX9t//q6oeB/EtFt Aq2VBPXwlArG1emdiSzx9Xl764ZMy1MOHwIzwhXzhwATkUtfKiAiHUNXlO68sMHBt6Qp/WT 5Z72lFPjpgNffpNGRkDuebxTDVe7M0SljyfNdSZd0upcMBnQLfCsAn0AEmxELKS27NNdRHk GHrjPh8exudSwDwvxXWtA== X-UI-Out-Filterresults: notjunk:1;V01:K0:UQK0H+4sqqM=:jvaROh+7FZsQuK3jncwf7v sh1FYMLfXfh02VJc/MGDyKX1qqJ7JU+fyiOUXqX7SQcfaDiuYLIh1UcXeD2tPw3+N1bC5t13L hZMPuuL9NuwIEYeJBcsAZvjrONiFor2DowvfbTPFz5VXlEFt1mbhSsyVyMtssQ3CcFxMxqRQy 0OhTAB9wh6TBeOC5xQmsMzblKcoHaLIyngKTy1RfdxY/afSOW/g/yscz/QUE8XCrf5idnabQK kCqPP0iovewnIW4KpeMGt7JdL876RkXU9T/W6N0DyGbcULwJ3MzpL8CizkiDExr64KbiiV17N cA9vEYbV2MXzMFl+Oa03GqUe4KycGrTQML1MCX5Hxy0J18P5cRTtYQ2QIgq3hMZpT+wEKoWEd ihtnDgvEI+cN1NPCX9Y5BUkRgToKj+inwTjt4xe+KMZlCUrsKZZ1AHHI9Sk+Bi8O1B+oLOPrq bfnXhf9BSFtJLau/1OvasWmIjn2D7560r63/WSojV8+DDvwEnavYJXGtsER3Ci62bKi5Jz7jz DilYxt41lVuEoDZz5br/MKWNMtd9EveSJ5x3p3WXodLEddJ4LQzf5hWmHFZ1MrY55xo/nBYBl 48BFehJrImp8iUvEPVfO3FXBj+p8WCSdpFigU38K6sw3FeaaeQOCJgDJARsEfbM/xJowL6LMl yODkQyTJ5hTzvdo0XyyDojE4+8VtTiaSyFQFRWJeu/IaVLlftmyWcpHQ8LoDSSnTv1kQ3Xjwk OSOb2+QTet1ElcPcKmlHdb9Z+JZeDldkXN/H2MsZGVgNzevnOAnRXy3X/XrZUJRngPYbYtWej UR2rJzc Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> I hope so. - I propose to give the refactorings "Reduce scope of variable" >> and "Extract a function" (and the corresponding consequences) another look. > > So you _think_ it does. Come back with real proof. Which test environments would you find acceptable for further clarification? > I must also point out that these sorts of optimisations are things the > compiler does automatically when compiling this code. Do you take this detail for granted? > Therefore it's highly likely that this change will make absolutely > no difference whatsoever. I find this outcome unlikely. > (And no it won't improve compile speed in any justifiable way) This was not a goal of my update suggestion for the function "bpf_jit_compile". >> It is generally possible that a specific code generation variant will also affect >> the run time properties you mentioned. > > It's _possible_? Come back with benchmarks. Which code generation variant would be useful to be clarified further? Should we avoid to compare software things similar to "apples" and "oranges" (while these fruits can make more fun)? ;-) > I must also point out that this is a "slow path" i.e. as long as it's > not stupidly inefficient, the speed doesn't matter that much. Can this execution path become warmer (or even "hot") for some other use cases? > This change isn't going to improve the speed of this function by any amount > that matters. This is also possible. > Unless you have some pretty damn good proof that these changes improve things, > there is absolutely no reason to take them as-is Would you care for a better source code structure? > - you are making the code longer Yes. - This is true for the suggested update in this function. > and more difficult to read for no benefit I proposed specific benefits for this software module. > and wasting everyone's time in the process. I assume that a few contributors can take the presented ideas for further considerations. Will their value evolve a bit more later? Regards, Markus