Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1701423 > unrolled thread

Re: [PATCH 09/28] x86/intel_rdt/cqm: Add RMID(Resource monitoring ID) management

Started byThomas Gleixner <tglx@linutronix.de>
First post2017-08-01 22:20 +0200
Last post2017-08-02 09:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 09/28] x86/intel_rdt/cqm: Add RMID(Resource monitoring  ID) management Thomas Gleixner <tglx@linutronix.de> - 2017-08-01 22:20 +0200
    Re: [PATCH 09/28] x86/intel_rdt/cqm: Add RMID(Resource monitoring  ID) management Shivappa Vikas <vikas.shivappa@intel.com> - 2017-08-02 09:50 +0200

#1701423 — Re: [PATCH 09/28] x86/intel_rdt/cqm: Add RMID(Resource monitoring ID) management

FromThomas Gleixner <tglx@linutronix.de>
Date2017-08-01 22:20 +0200
SubjectRe: [PATCH 09/28] x86/intel_rdt/cqm: Add RMID(Resource monitoring ID) management
Message-ID<u9LO1-9K-1@gated-at.bofh.it>
On Tue, 25 Jul 2017, Vikas Shivappa wrote:
> Hardware uses RMID(Resource monitoring ID) to keep track of each of the
> RDT events associated with tasks. The number of RMIDs is dependent on
> the SKU and is enumerated via CPUID. We add support to manage the RMIDs
> which include managing the RMID allocation and reading LLC occupancy
> for an RMID.
> 
> RMID allocation is managed by keeping a free list which is initialized
> to all available RMIDs except for RMID 0 which is always reserved for
> root group. RMIDs goto a limbo list once they are
> freed since the RMIDs are still tagged to cache lines of the tasks which
> were using them - thereby still having some occupancy. They continue to
> be in limbo list until the occupancy < threshold_occupancy. The
> threshold_occupancy is a user configurable value.
> OS uses IA32_QM_CTR MSR to read the occupancy associated with an RMID
> after programming the IA32_EVENTSEL MSR with the RMID.
> 
> [Tony: Improved limbo search]

The search is smarter, but the smp function call problem per se
persists. It's still more than 100us worstcase on a BDW box and it's going
to be worse with the next generation.

Thanks,

	tglx

[toc] | [next] | [standalone]


#1701805

FromShivappa Vikas <vikas.shivappa@intel.com>
Date2017-08-02 09:50 +0200
Message-ID<u9WzM-6Xn-19@gated-at.bofh.it>
In reply to#1701423

On Tue, 1 Aug 2017, Thomas Gleixner wrote:

> On Tue, 25 Jul 2017, Vikas Shivappa wrote:
>> Hardware uses RMID(Resource monitoring ID) to keep track of each of the
>> RDT events associated with tasks. The number of RMIDs is dependent on
>> the SKU and is enumerated via CPUID. We add support to manage the RMIDs
>> which include managing the RMID allocation and reading LLC occupancy
>> for an RMID.
>>
>> RMID allocation is managed by keeping a free list which is initialized
>> to all available RMIDs except for RMID 0 which is always reserved for
>> root group. RMIDs goto a limbo list once they are
>> freed since the RMIDs are still tagged to cache lines of the tasks which
>> were using them - thereby still having some occupancy. They continue to
>> be in limbo list until the occupancy < threshold_occupancy. The
>> threshold_occupancy is a user configurable value.
>> OS uses IA32_QM_CTR MSR to read the occupancy associated with an RMID
>> after programming the IA32_EVENTSEL MSR with the RMID.
>>
>> [Tony: Improved limbo search]
>
> The search is smarter, but the smp function call problem per se
> persists. It's still more than 100us worstcase on a BDW box and it's going
> to be worse with the next generation

As an alternative we could have delayed worker threads(hence not in interrupt 
context) every 1s to check the limbo lists using the same optimized search with 
1 bit per RMID.

When a mkdir tries to get RMID if no RMID is in free list and some are present 
in limbo we return -EBUSY and if both free and limbo lists are empty we return 
-ENOSPC.

If that is reasonable I can send an updated patch for the same.

Thanks,
Vikas

>
> Thanks,
>
> 	tglx
>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web