linux-kernel - Re: [PATCH 08/10] x86/intel_rdt: Implement scheduling support for Intel RDT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1506080920210.30856@vshiva-Udesk>
Date:	Mon, 8 Jun 2015 09:30:20 -0700 (PDT)
From:	Vikas Shivappa <vikas.shivappa@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
	linux-kernel@...r.kernel.org, vikas.shivappa@...el.com,
	x86@...nel.org, hpa@...or.com, mingo@...nel.org, tj@...nel.org,
	peterz@...radead.org, matt.fleming@...el.com, will.auld@...el.com,
	kanaka.d.juvva@...el.com
Subject: Re: [PATCH 08/10] x86/intel_rdt: Implement scheduling support for
 Intel RDT



On Sat, 6 Jun 2015, Thomas Gleixner wrote:

> On Thu, 4 Jun 2015, Vikas Shivappa wrote:
>> +static inline void intel_rdt_sched_in(void)
>> +{
>> +	if (static_key_false(&rdt_enable_key))
>> +		__intel_rdt_sched_in();
>
> So if the enable_key is FALSE we call the RDT stuff? I might be
> missing something important, but this does not make any sense and I
> have to ask how that whole stuff has been tested.
>
>>  /*
>>   * Protects cache_cgroups and cqm_rmid_free_lru and cqm_rmid_limbo_lru.
>> @@ -403,8 +384,8 @@ static void __intel_cqm_event_count(void *info);
>>  static u32 intel_cqm_xchg_rmid(struct perf_event *group, u32 rmid)
>>  {
>>  	struct perf_event *event;
>> -	struct list_head *head = &group->hw.cqm_group_entry;
>>  	u32 old_rmid = group->hw.cqm_rmid;
>> +	struct list_head *head = &group->hw.cqm_group_entry;
>
> And this change is necessary because?

Was a minor thing.
Changed this to keep the length in increasing order but it 
should have been 
decreasing order to be consistent with other functions in cqm. For some reason 
the length was  actually in increasing order in earlier versions of cqm.

Will fix this.

Thanks,
Vikas

>
> Thanks,
>
> 	tglx
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/