From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S936644AbcIWNE4 (ORCPT <rfc822;w@1wt.eu>);
        Fri, 23 Sep 2016 09:04:56 -0400
Received: from mail-yw0-f176.google.com ([209.85.161.176]:35053 "EHLO
        mail-yw0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S935395AbcIWNEn (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 23 Sep 2016 09:04:43 -0400
MIME-Version: 1.0
In-Reply-To: <48278d51-67b6-2c95-71e4-e922072ad9e9@users.sourceforge.net>
References: <566ABCD9.1060404@users.sourceforge.net> <2f3f7ad7-16a0-1dfb-d073-0d993cd767ee@users.sourceforge.net>
 <0be7fee0-64f7-fa02-0337-51376677343e@users.sourceforge.net>
 <e9b443c7-2947-46d5-462f-58c175b774bc@ti.com> <d9b20442-3f84-82bd-d600-e3045a21da99@users.sourceforge.net>
 <CAF6AEGsHS9P0XyVH=So9woCkp9u8mUgL1QrCFNzgWdy26_4rDw@mail.gmail.com>
 <3b791118-2977-f607-b816-dd5e833cfc75@users.sourceforge.net>
 <CAF6AEGsh34CNfP6kwGV7nHFfPGp=Vbvja=_6FDuc0XPChJ2Kaw@mail.gmail.com> <48278d51-67b6-2c95-71e4-e922072ad9e9@users.sourceforge.net>
From: Rob Clark <robdclark@gmail.com>
Date: Fri, 23 Sep 2016 09:04:42 -0400
Message-ID: <CAF6AEGs9EDX3=kDDvQSh_-4sTbP6-psvZX8WAudV-PpigKCBtg@mail.gmail.com>
Subject: Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node()
 after error detection
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: Jyri Sarha <jsarha@ti.com>, kernel-janitors@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        Julia Lawall <julia.lawall@lip6.fr>,
        Tomi Valkeinen <tomi.valkeinen@ti.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Sep 23, 2016 at 8:17 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
>>> I see a need to improve not only correctness there but also a bit of
>>> software efficiency.
>>
>> If you can measure any performance difference and present some results
>> (esp. considering that this is something that just happens when the
>> driver is loaded), then we'll talk.
>
> Are you really interested to increase your software development attention
> for a quicker exception handling implementation in this function?
>

No one is interested in making error handling more complex for a
non-existent benefit ;-)

>
>> Until then, please don't send this sort of patch.  Thank you.
>
> Will benchmark statistics change such a change rejection ever?

If you could demonstrate a real benefit to additional complexity for
something that actually matters (ie. not something like this that runs
once at bootup) I would care.

I don't recommend that you waste your time, since there is
approximately nothing in modesetting path that happens with a high
enough frequency to benefit from such a micro-optimization.
Especially not initialization code that runs once at boot up.

Fixing actual bugs is useful and valuable.  Premature "optimization"
at the expense of extra complexity is very much not useful.

BR,
-R

> Regards,
> Markus