From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Christian_K=F6nig?= Subject: Re: [PATCH] drm/radeon: Inline r100_mm_rreg Date: Fri, 11 Apr 2014 10:33:08 +0200 Message-ID: <5347A8C4.90307@vodafone.de> References: <20140410160817.5275493d.cand@gmx.com> <20140410214634.ba440af5.cand@gmx.com> <5346F13B.6060604@vodafone.de> <20140411105201.57ea4a1b.cand@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 9EB6D6E365 for ; Fri, 11 Apr 2014 01:33:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix1 Daemon) with ESMTP id BFD702613B3 for ; Fri, 11 Apr 2014 10:33:21 +0200 (CEST) Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix1.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMNftpDoef4C for ; Fri, 11 Apr 2014 10:33:16 +0200 (CEST) In-Reply-To: <20140411105201.57ea4a1b.cand@gmx.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Lauri Kasanen Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org Am 11.04.2014 09:52, schrieb Lauri Kasanen: > On Thu, 10 Apr 2014 21:30:03 +0200 > Christian K=F6nig wrote: > >>>>> Quick thought from someone entirely unfamiliar with the hardware: >>>>> perhaps you can get the performance benefit without the size increase >>>>> by moving the else portion into a non-inline function? I'm guessing >>>>> that most accesses happen in the "if" branch. >>>> The function call overhead is about equal to branching overhead, so >>>> splitting it would only help about half that. It's called from many >>>> places, and a lot of calls per sec. >> Actually direct register access shouldn't be necessary so often. Apart >> from page flips, write/read pointer updates and irq processing there >> shouldn't be so many of them. Could you clarify a bit more what issue >> you are seeing here? > Too much cpu usage for such a simple function. 2% makes it #2 in top-10 > radeon.ko functions, right after evergreen_cs_parse. For reference, #3 > (radeon_cs_packet_parse) is only 0.5%, one fourth of this function's > usage. I think you misunderstood me here. I do believe your numbers that it = makes a noticeable difference. But I've did a couple of perf tests recently on SI and CIK while hacking = on VM support, and IIRC r100_mm_rreg didn't showed up in the top 10 on = those systems. So what puzzles me is who the hack is calling r100_mm_rreg so often that = it makes a noticeable difference on evergreen/NI? Christian. > > As proved by the perf increase, it's called often enough that getting > rid of the function call overhead (and compiling the if out > compile-time) helps measurably. > > - Lauri