All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shivappa Vikas <vikas.shivappa@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Vikas Shivappa <vikas.shivappa@linux.intel.com>,
	vikas.shivappa@intel.com, linux-kernel@vger.kernel.org,
	x86@kernel.org, hpa@zytor.com, mingo@kernel.org,
	peterz@infradead.org, ravi.v.shankar@intel.com,
	tony.luck@intel.com, fenghua.yu@intel.com,
	h.peter.anvin@intel.com
Subject: Re: [PATCH 8/8] x86/intel_rdt: rmdir,umount and hotcpu updates for MBA
Date: Mon, 23 Jan 2017 12:18:07 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1701231146250.3301@vshiva-Udesk> (raw)
In-Reply-To: <alpine.DEB.2.20.1701161710350.3877@nanos>



On Mon, 16 Jan 2017, Thomas Gleixner wrote:

> On Tue, 10 Jan 2017, Vikas Shivappa wrote:
>
>> During rmdir only reset the ctrl values for the rdtgroup's closid. This
>> is done so that that next time when the closid is reused they dont
>> reflect old values.
>
> How on earth is that related to MBA?

This is not specific to MBA so i put it as x86/intel_rdt in the subject but will 
send this as part of seperate series which you mentioned.

>
>> Remove the closid update during cpuonline in cqm as its
>> already in the CAT code. Since both cqm and CAT want the rmid and closid
>> to be zero when cpu is online, remove the PQR MSR write to zero during
>> cpuonline because the MSRs are at zero after cpu reset and also during
>
> Are you sure that the MSRs are zero when the cpu goes offline and then
> online again? That's not a reset.

Thats right - I was removing this since at the first sched_in the new CLOSID 
would be updated anyways. I know this prevents from having a 0 CLOSid at the 
time all the hot plug code is run, but we already have run the __cpu_disable and 
all the hotplug code when going down on the last used CLOSid. (if the kernel 
thread that handles the offline/online should have a 0 CLOS then thats fine 
probably..)
So may be the right way is to actually zero the CLOS in PQR_MSR when we are 
going down/offline ?

Thanks,
Vikas

>
> Thanks,
>
> 	tglx
>

      reply	other threads:[~2017-01-23 20:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 19:33 [PATCH 0/8 V1] x86/intel_rdt: Memory b/w Allocation support Vikas Shivappa
2017-01-10 19:33 ` [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w allocation user interface Vikas Shivappa
2017-01-16 13:43   ` Thomas Gleixner
2017-01-18  0:51     ` Shivappa Vikas
2017-01-18  9:01       ` Thomas Gleixner
2017-01-23 18:57         ` Shivappa Vikas
2017-01-23 19:01           ` Thomas Gleixner
2017-01-24 22:10             ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 2/8] x86/intel_rdt/mba: Generalize the naming to get ready for MBA Vikas Shivappa
2017-01-16 13:45   ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 3/8] x86/intel_rdt/mba: Improvements to handle more RDT resources like MBA Vikas Shivappa
2017-01-16 13:54   ` Thomas Gleixner
2017-01-18  0:53     ` Shivappa Vikas
2017-01-18  9:05       ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 4/8] x86/intel_rdt/mba: Memory b/w allocation feature detect Vikas Shivappa
2017-01-16 13:59   ` Thomas Gleixner
2017-01-16 14:41     ` Peter Zijlstra
2017-01-16 16:16       ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 5/8] x86/intel_rct/mba: Add MBA structures and initialize MBA Vikas Shivappa
2017-01-16 14:06   ` Thomas Gleixner
2017-01-18  0:56     ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 6/8] x86/intel_rdt/mba: Add info directory files for MBA Vikas Shivappa
2017-01-16 14:14   ` Thomas Gleixner
2017-01-18  1:02     ` Shivappa Vikas
2017-01-18  9:08       ` Thomas Gleixner
2017-01-23 19:45         ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 7/8] x86/intel_rdt/mba: Add schemata file support " Vikas Shivappa
2017-01-16 16:07   ` Thomas Gleixner
2017-01-18  1:03     ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 8/8] x86/intel_rdt: rmdir,umount and hotcpu updates " Vikas Shivappa
2017-01-16 16:13   ` Thomas Gleixner
2017-01-23 20:18     ` Shivappa Vikas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1701231146250.3301@vshiva-Udesk \
    --to=vikas.shivappa@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=h.peter.anvin@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.