From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759905AbbCDJw6 (ORCPT ); Wed, 4 Mar 2015 04:52:58 -0500 Received: from service87.mimecast.com ([91.220.42.44]:41915 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757258AbbCDJw4 convert rfc822-to-8bit (ORCPT ); Wed, 4 Mar 2015 04:52:56 -0500 Message-ID: <54F6D5FA.6000307@arm.com> Date: Wed, 04 Mar 2015 09:52:58 +0000 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Borislav Petkov , Andre Przywara , Tejun Heo CC: Sudeep Holla , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" Subject: Re: [PATCH RFT v2] x86: move cacheinfo sysfs to generic cacheinfo infrastructure References: <20150224175749.GC3575@pd.tnic> <1425249564-28347-1-git-send-email-andre.przywara@arm.com> <20150303184527.GE3648@pd.tnic> In-Reply-To: <20150303184527.GE3648@pd.tnic> X-OriginalArrivalTime: 04 Mar 2015 09:52:53.0288 (UTC) FILETIME=[FBAAFA80:01D05660] X-MC-Unique: 115030409525400401 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/15 18:45, Borislav Petkov wrote: [...] > Now, previously the code did > > - if (!per_cpu(ici_cpuid4_info, i)) > - continue; > > > and __cache_cpumap_setup() already does: > > if (i == cpu || !sib_cpu_ci->info_list) > continue;/* skip if itself or no cacheinfo */ > > so maybe we should do that too in __cache_amd_cpumap_setup(): > > if (!this_cpu_ci->info_list) > continue; > > for the index == 3 case? > > It boots fine here with that change and it is consistent with the > previous code. > Ok, I will add the above check. Sorry for missing that. > And yes, the x86 cacheinfo code could use a serious rubbing and cleanup. > > Btw, this patch introduces a bunch of new sysfs nodes in the caches > hierarchy: > > --- caches-guest-before.txt 2015-03-03 15:11:09.168276423 +0100 > +++ caches-guest-after.txt 2015-03-03 18:19:04.084426130 +0100 > @@ -1,6 +1,22 @@ > +/sys/devices/system/cpu/cpu0/cache/power/control:1:auto > +/sys/devices/system/cpu/cpu0/cache/power/async:1:disabled > +/sys/devices/system/cpu/cpu0/cache/power/runtime_enabled:1:disabled > +/sys/devices/system/cpu/cpu0/cache/power/runtime_active_kids:1:0 > +/sys/devices/system/cpu/cpu0/cache/power/runtime_active_time:1:0 > +/sys/devices/system/cpu/cpu0/cache/power/runtime_status:1:unsupported > +/sys/devices/system/cpu/cpu0/cache/power/runtime_usage:1:0 > +/sys/devices/system/cpu/cpu0/cache/power/runtime_suspended_time:1:0 > /sys/devices/system/cpu/cpu0/cache/index0/size:1:64K > /sys/devices/system/cpu/cpu0/cache/index0/type:1:Data > /sys/devices/system/cpu/cpu0/cache/index0/level:1:1 > +/sys/devices/system/cpu/cpu0/cache/index0/power/control:1:auto > +/sys/devices/system/cpu/cpu0/cache/index0/power/async:1:disabled > +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_enabled:1:disabled > +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_active_kids:1:0 > +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_active_time:1:0 > +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_status:1:unsupported > +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_usage:1:0 > +/sys/devices/system/cpu/cpu0/cache/index0/power/runtime_suspended_time:1:0 > /sys/devices/system/cpu/cpu0/cache/index0/number_of_sets:1:512 > /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_map:1:1 > /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list:1:0 > ... > > What do those things mean? runtime_active_kids ?? Kids are active during > runtime?! Well, that's a given, no need for a sysfs node for that :-) > Those extra sysfs are due to that fact that generic cacheinfo sysfs is not using raw kobjects directly anymore (which was the case with most of the old cacheinfo sysfs implementation), but uses device/device attributes as Greg suggested to simply the code and reuse device model code. Regards, Sudeep