linux-kernel - Re: [PATCH 7/9] 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: <55C3E7B0.2010609@kernel.org>
Date:	Thu, 6 Aug 2015 16:03:12 -0700
From:	Andy Lutomirski <luto@...nel.org>
To:	Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
	vikas.shivappa@...el.com
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org, hpa@...or.com,
	tglx@...utronix.de, mingo@...nel.org, tj@...nel.org,
	peterz@...radead.org, matt.fleming@...el.com, will.auld@...el.com,
	glenn.p.williamson@...el.com, kanaka.d.juvva@...el.com
Subject: Re: [PATCH 7/9] x86/intel_rdt: Implement scheduling support for Intel
 RDT

On 08/06/2015 02:55 PM, Vikas Shivappa wrote:
> Adds support for IA32_PQR_ASSOC MSR writes during task scheduling. For
> Cache Allocation, MSR write would let the task fill in the cache
> 'subset' represented by the task's intel_rdt cgroup cache_mask.
>
> The high 32 bits in the per processor MSR IA32_PQR_ASSOC represents the
> CLOSid. During context switch kernel implements this by writing the
> CLOSid of the cgroup to which the task belongs to the CPU's
> IA32_PQR_ASSOC MSR.
>
> This patch also implements a common software cache for IA32_PQR_MSR
> (RMID 0:9, CLOSId 32:63) to be used by both Cache monitoring (CMT) and
> Cache allocation. CMT updates the RMID where as cache_alloc updates the
> CLOSid in the software cache. During scheduling when the new RMID/CLOSid
> value is different from the cached values, IA32_PQR_MSR is updated.
> Since the measured rdmsr latency for IA32_PQR_MSR is very high (~250
>   cycles) this software cache is necessary to avoid reading the MSR to
> compare the current CLOSid value.
>
> The following considerations are done for the PQR MSR write so that it
> minimally impacts scheduler hot path:
>   - This path does not exist on any non-intel platforms.
>   - On Intel platforms, this would not exist by default unless CGROUP_RDT
>   is enabled.
>   - remains a no-op when CGROUP_RDT is enabled and intel SKU does not
>   support the feature.
>   - When feature is available and enabled, never does MSR write till the
>   user manually creates a cgroup directory *and* assigns a cache_mask
>   different from root cgroup directory. Since the child node inherits
>   the parents cache mask, by cgroup creation there is no scheduling hot
>   path impact from the new cgroup.
>   - MSR write is only done when there is a task with different Closid is
>   scheduled on the CPU. Typically if the task groups are bound to be
>   scheduled on a set of CPUs, the number of MSR writes is greatly
>   reduced.
>   - A per CPU cache of CLOSids is maintained to do the check so that we
>   dont have to do a rdmsr which actually costs a lot of cycles.
>   - For cgroup directories having same cache_mask the CLOSids are reused.
>   This minimizes the number of CLOSids used and hence reduces the MSR
>   write frequency.

What happens if a user process sets a painfully restrictive CLOS and 
then spends most of its time in the kernel doing work on behalf of 
unrelated tasks?  Does performance suck?

--Andy
--
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/