From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934605AbbIVUOX (ORCPT ); Tue, 22 Sep 2015 16:14:23 -0400 Received: from mail-bn1on0140.outbound.protection.outlook.com ([157.56.110.140]:55796 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933812AbbIVUOV (ORCPT ); Tue, 22 Sep 2015 16:14:21 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scottwood@freescale.com; Message-ID: <1442952852.19102.281.camel@freescale.com> Subject: Re: [PATCH v2 22/25] powerpc32: move xxxxx_dcache_range() functions inline From: Scott Wood To: Joakim Tjernlund CC: "christophe.leroy@c-s.fr" , "paulus@samba.org" , "mpe@ellerman.id.au" , "benh@kernel.crashing.org" , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Date: Tue, 22 Sep 2015 15:14:12 -0500 In-Reply-To: <1442951752.29498.58.camel@transmode.se> References: <1442945547.29498.50.camel@transmode.se> <1442948339.19102.270.camel@freescale.com> <1442950473.29498.54.camel@transmode.se> <1442950926.19102.280.camel@freescale.com> <1442951752.29498.58.camel@transmode.se> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.0-fta1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [2601:448:8100:f9f:d59:7025:7bba:8c10] X-ClientProxiedBy: BLUPR11CA0075.namprd11.prod.outlook.com (10.141.30.43) To BLUPR03MB1474.namprd03.prod.outlook.com (25.163.81.16) X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1474;2:a05fB+CfOINPyjnr94zxty+Ha53yDD8o6VlWH60Th1Ykl0bNY3m5Ynkwb5J7EodkglkLRWpLuA70uk+0eJZzBGcwFHnf52GWRUlaWEF9kXipn4ah2tXvmqzSujpCK+106gWD6I9txoMEjUuq6jTHYeX16aq4ZT+qlnCbqc2D/Fw=;3:EU4nzZowWRH2qJuoXges/8AYArHg1hylNr91HrH+mw9fbENf8kjZkD58xv7ToDhgXff3y0BHMgscNoruketZBZK1la2bp98b1r89Wagrax8rFOsyA+DiChTmzRw6073gaxuL7kRr5bTkKLpLsmHiDw==;25:HxKTKyYlvqCxkcsjEZ4HbwSJPZFrZBJZqlFXw4G+Ak4o5cUFWXa2bL7Ybeh3eVt9PHcyriTgEaakmVgw2W7X30VdhafVu6GKliwcmJXWCb8GawZZgjNqKRmwpg5/aSYwEdUBxu60xdOf0nPKVmu5thblXC/7f/4vFY4Xu6qfqvy4g2ZCUcfTTc3rRKzzQv8xiAjfxxGrTc6QCsXjQ3BFvfJ607CfHiiJYqSFp1/wx4sqvLZYlvtvRqHkL6fHQmjeS6n5Y5N5YSNNCIt5kSyTtQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1474; X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1474;20:j76ggrXkCIrkISTVh8GZMMEl/JaB8maNPW+6KLfvWjx4GqswG+GEvlHC//qlRwwFC2rW/yN0E2lkDfbJNtPvjvKnNJA9NSbH19Cfz6Am3v8l8ppCAQNdDuWKGrst8j68gLpRneMUmhOUPKTep+DmIwc3LVQEfKLcI6QF6jWxEZvprlh3HQIjRd7v5gFJiWIyglJ2qV3hBmXTP8JfHCSVu5vUwcW0xs/K5c4HVDC8Xahj7mllKewd/9rl3lnkDEragSNMpwcXwveXJtQltWrfduQ+NDykPCbzuvBtKRG/uzndugEXpj9UkIjc1eWhUR0bfnTLom1xkLdbzXRZ/gqKuYl2GI4UhvhgR4ccH1bA0YUGFp6KpZyVSuhj4nSV5TMtTXUdOePPRQAIUlBBds2F/vvoOae10W9zSmF0b67UDSuVDcZdeMC3miKHE2AhIM9Vf+N5cQAPQS9lvsIa++MAmapxRMhIEjtgnddUxIKWTjEz164JULGLBoVf5hdQyCOI;4:jz9S0gK/Ydlu64nrQ2gmpbt9A7JiWJMhbrLbOFsE2lZJyKXSBqnmHfCVNI+9KAqFrme4z1NqzS5MMpplprR9im4VtaLAQZzdPBYPj6s/5Q2FyzT7slrq9HYdSTe40MbNOWmcULEXUJtrYAbj5Ios1WoryxtQBUgHQRXGH5tUIzTeopn0oId3YcWAWZRKyMmGzQRZ6qSJPtqsLw2LIO6U2BnPgmOnLmDDF1gOUOomjQFh9HoYDw8BIRabJs1IYaPeYT85Fuxq2Z6gbX0a2tomJCr5ygToyM1YguYPLbkpqjkG5Vb9IX/uC2viZqOqj5tO+4ubu07+YDIDdlennWTiFcpZXdh6Uo1Qp+u1qop+RLk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001);SRVR:BLUPR03MB1474;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1474; X-Forefront-PRVS: 0707248B64 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(377424004)(199003)(189002)(24454002)(122386002)(62966003)(93886004)(101416001)(46102003)(33646002)(47776003)(42186005)(87976001)(86362001)(64706001)(50466002)(5007970100001)(81156007)(5001830100001)(103116003)(50986999)(19580405001)(2950100001)(50226001)(4001540100001)(36756003)(5820100001)(105586002)(189998001)(5004730100002)(5001920100001)(97736004)(110136002)(92566002)(40100003)(76176999)(23676002)(106356001)(77096005)(68736005)(5001860100001)(77156002)(5001960100002)(99106002)(3826002)(5001840100002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR03MB1474;H:[IPv6:2601:448:8100:f9f:d59:7025:7bba:8c10];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjAzTUIxNDc0OzIzOjFVY0lUbDJtc2U5ZkwwdkQ4OWNMeE9WaURC?= =?utf-8?B?dW1oN3RkN0Y1N2xvSEVwc3RKazdyUmlyM1F2anhqSlB0bHM1dFNJUmREK2s4?= =?utf-8?B?NWNhcy9aRDlCQVV0RXhYY0JEbW04YjNrNEcyMzIyazU4eCtYYXZieUp6cUdG?= =?utf-8?B?ZE84YStta3RHMVRHNmJCODFxaHlvWkd3MHYxUVFLa29EbFc1TnhKdWZnZ0pU?= =?utf-8?B?QVkyeG1sYzFvcTdzZjhpWXdmQk1tQ2xJVmhnOFB4MSsvS3hISVhnV0hBQWRq?= =?utf-8?B?Wm1NVHVhb3kwNVJ5alRhaE41RVRSbEoveWZiRnhMV3pVVXhlcXF0by9uZXY4?= =?utf-8?B?RE05WlFFdDRJYzZodUJGbEM2Tm9BYXJkNVAxRmkrYzJKSys1N1NMUWsxSlpk?= =?utf-8?B?VkJwbDlpTmF1cFNSS0duZzJheTFvaW9rclhPVnVYYm5VTjIyZXhLSVFoVURG?= =?utf-8?B?SzZzWXJBMGhFZExrK0FzMlBSZkVaZkhJNjhMTklYVE92bmgyNmpXMndaTWNU?= =?utf-8?B?TnllNmtlcDg2WUJzeWI5alVwZmlCbnNLamxES0hZdGJTRnNPNWhia2M3Wk9J?= =?utf-8?B?R0JYNDhILzIwTndzekZvWmdoY1JXbURJb2hvNlkxQ0tWWGZZeHdyZ0lpZHlE?= =?utf-8?B?QWhiek5SdXg4bnJDa29jL0FIOURBT0xuSCtiUEQza2lLTmZWa0djdTM0eWRF?= =?utf-8?B?MmhGdms4cUFDbmZId2YwVjg2UkJzK25mMTB6SDBJWDdWbWZnQTZLVjBtQXN0?= =?utf-8?B?SUVKNnB0djJHQ2RYOXlRaThYMHIxZEZKWXk4bG9UdjBQZ29kVHBodWV6Y0dj?= =?utf-8?B?Yk5Yai9EQ0c1MGtXcm1LOHJiNjNWZXdVRGNoWVJ4QzlrN3VqOCthQ1FkbCs3?= =?utf-8?B?Q1pqNE9MeG5PMitNZGFXM1NOdUxEWUdhejQ4WTZSUEI0c2VSOFUvRGhpYXBG?= =?utf-8?B?SWJjNFQxclZQbEdjNGtLLzAvWEw4cXh3UVpxZi9Nd25jN2hJVm9xZVVxWHlV?= =?utf-8?B?U3JQc1dJa1puZ1diK2xUM3JoejdOWUpodmx1enU2SUNNQ29RYVVPU0RtMU9U?= =?utf-8?B?anlBNzE1amNobDREUnptT3kvbS9tYmJVdWJ0SlFMR3BaZGVKMEx1bURQY0FB?= =?utf-8?B?WU5HdVRhSEZoWjFUejk2SU83OEtQMXh1ZndTS0RWWjJodkR2a2F2VkZNb1du?= =?utf-8?B?b2Zrenk5U0FxY0hkTEwvblFJSHV4Yk5YdU9WMUtCUHovMUhHY1FBV0g0NTVm?= =?utf-8?B?dHB0QUtVdW1QWGd5N2tkVEdybzlXajZtM1cxaG5SZEl2TTZjcDJsMkk3bnh0?= =?utf-8?B?S2RvUXIzcXZYbXNkUDVlL2tWYkxxait2bTBsUzA2eWdJNUJaRDd0aEt4WmNT?= =?utf-8?B?YTZsY3hZQ0pTMHhKL3Uvb1FsdDlMb3RtbjNjZnJVS2lFeHhieG10VWxMQmpW?= =?utf-8?B?QXBUa3FUeTBncjJ1VnJ3SnVsTFRZMVBsSHArNzRMNElodCsxbjhtVTVrYkVH?= =?utf-8?B?RExlNjlzalo3UEpGMklQSU5CSE5FVE56Y3I0V3h1cmdXSHh3RE1YanVIWUxF?= =?utf-8?B?TjJCK3o1Q0JSMGRyM29lR1VvaGluMGRPTnYwK2laUk9wRHVIT0xUL1diK2Yy?= =?utf-8?B?UGNaZUU0M05qWXhFK2k5aFNMYytZVFpVV09uV0VhaC9yQnpHckNGQndtQ05z?= =?utf-8?Q?ad6O7aFtZUQzvUTPVjKA8DzauUMSceWUGh5+LsX?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1474;5:jn7y5JFbdMxWDRBnZzQiQKPbA99qgeTrmBckoPYXNo0dqUXdxTSNrCYJikSL0UeAcPOY3TdqrCBy+7f99ZPK/xcV5oZVGxDMDQba47qxl2UkAbxWlISYiHAxIaJlZekXSyM0sWXpmDjotmsnogKsqg==;24:2jyNWgnjtN4cUOtrQxctVJ2f06lHQxivon0dBBQkgb2ZD72o9T7RKsV74siGA1rwR/fbGuGrXV8MwHIeEKpeXzewxu3M6fADUmQmC2CY3z0=;20:R/k9vsmohwmbwpE3/rvMx9qh0i2bW8x2EiCLWs6TlRsfu5IdKoylmkYKxwT421x3AqekWisb+vbpz1JOZSemVg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2015 20:14:18.4772 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1474 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2015-09-22 at 19:55 +0000, Joakim Tjernlund wrote: > On Tue, 2015-09-22 at 14:42 -0500, Scott Wood wrote: > > On Tue, 2015-09-22 at 19:34 +0000, Joakim Tjernlund wrote: > > > On Tue, 2015-09-22 at 13:58 -0500, Scott Wood wrote: > > > > On Tue, 2015-09-22 at 18:12 +0000, Joakim Tjernlund wrote: > > > > > On Tue, 2015-09-22 at 18:51 +0200, Christophe Leroy wrote: > > > > > > flush/clean/invalidate _dcache_range() functions are all very > > > > > > similar and are quite short. They are mainly used in __dma_sync() > > > > > > perf_event locate them in the top 3 consumming functions during > > > > > > heavy ethernet activity > > > > > > > > > > > > They are good candidate for inlining, as __dma_sync() does > > > > > > almost nothing but calling them > > > > > > > > > > > > Signed-off-by: Christophe Leroy > > > > > > --- > > > > > > New in v2 > > > > > > > > > > > > arch/powerpc/include/asm/cacheflush.h | 55 > > > > > > +++++++++++++++++++++++++++-- > > > > > > arch/powerpc/kernel/misc_32.S | 65 ---------------------- > > > > > > ---- > > > > > > ---- > > > > > > ----- > > > > > > arch/powerpc/kernel/ppc_ksyms.c | 2 ++ > > > > > > 3 files changed, 54 insertions(+), 68 deletions(-) > > > > > > > > > > > > diff --git a/arch/powerpc/include/asm/cacheflush.h > > > > > > b/arch/powerpc/include/asm/cacheflush.h > > > > > > index 6229e6b..6169604 100644 > > > > > > --- a/arch/powerpc/include/asm/cacheflush.h > > > > > > +++ b/arch/powerpc/include/asm/cacheflush.h > > > > > > @@ -47,12 +47,61 @@ static inline void > > > > > > __flush_dcache_icache_phys(unsigned long physaddr) > > > > > > } > > > > > > #endif > > > > > > > > > > > > -extern void flush_dcache_range(unsigned long start, unsigned > > > > > > long > > > > > > stop); > > > > > > #ifdef CONFIG_PPC32 > > > > > > -extern void clean_dcache_range(unsigned long start, unsigned > > > > > > long > > > > > > stop); > > > > > > -extern void invalidate_dcache_range(unsigned long start, > > > > > > unsigned > > > > > > long > > > > > > stop); > > > > > > +/* > > > > > > + * Write any modified data cache blocks out to memory and > > > > > > invalidate > > > > > > them. > > > > > > + * Does not invalidate the corresponding instruction cache > > > > > > blocks. > > > > > > + */ > > > > > > +static inline void flush_dcache_range(unsigned long start, > > > > > > unsigned > > > > > > long > > > > > > stop) > > > > > > +{ > > > > > > + void *addr = (void *)(start & ~(L1_CACHE_BYTES - 1)); > > > > > > + unsigned int size = stop - (unsigned long)addr + > > > > > > (L1_CACHE_BYTES - > > > > > > 1); > > > > > > + unsigned int i; > > > > > > + > > > > > > + for (i = 0; i < size >> L1_CACHE_SHIFT; i++, addr += > > > > > > L1_CACHE_BYTES) > > > > > > + dcbf(addr); > > > > > > + if (i) > > > > > > + mb(); /* sync */ > > > > > > +} > > > > > > > > > > This feels optimized for the uncommon case when there is no > > > > > invalidation. > > > > > > > > If you mean the "if (i)", yes, that looks odd. > > > > > > Yes. > > > > > > > > > > > > I THINK it would be better to bail early > > > > > > > > Bail under what conditions? > > > > > > test for "i = 0" and return. > > > > Why bother? > > I usally find it better to dela with special cases upfront så the rest > doesn't need to > bother. i=0 is a NOP and it is clearer to show that upfront. No, I mean why bother special casing this at all? -Scott