mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Cc: 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, andi.kleen@intel.com
Subject: Re: [PATCH 1/5] x86/intel_rdt: Update control registers only when user really modifies it
Date: Wed, 1 Mar 2017 14:31:35 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1703011412090.4005@nanos> (raw)
In-Reply-To: <1487360328-6768-2-git-send-email-vikas.shivappa@linux.intel.com>

On Fri, 17 Feb 2017, Vikas Shivappa wrote:

x86/intel_rdt: Update control registers only when user really modifies it

This hardly is a precise short summary.

> When a schemata is updated, the values for all the domains and all
> resources are entered.  However, the values for each of them may not
> change in many use cases as the user is only updating values for a
> subset of resources and domains. The resource control values are updated
> via QOS_MSRs which are per package. Change the update to QOS_MSRs to
> happen only when the control value on the particular domain is updated.
> Hence not sending IPIs on all domains when user updates the control
> vals.

Can you please structure your changelogs in a way which makes them
readable? The above is one big confusing lump. I asked you before to
provide changelogs which are properly structured:

 1) Context
 2) Problem
 3) Solution

and the sections to be precise and clear and not clobbered with completely
useless implementation details.

So a proper changelog for this would be:

 x86/intel_rdt: Avoid update of unchanged control registers

   Schemata files can only be updated as a whole, even if only a single
   value for a specific domain/resource changes.

   The current implementation updates all control registers unconditionally
   even if the values have not been changed by the schemata update. This
   results in pointless IPIs and MSR writes.

   Add a check whether the control register value actually changed and only
   update the affected CPUs.

Can you spot the difference?

> index f369cb8..14ba504 100644
> --- a/arch/x86/kernel/cpu/intel_rdt_schemata.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_schemata.c
> @@ -114,9 +114,16 @@ static int update_domains(struct rdt_resource *r, int closid)
>  	msr_param.high = msr_param.low + 1;
>  	msr_param.res = r;
>  
> +	/*
> +	 * Only update the domains that user has changed.
> +	 * There by avoiding unnecessary IPIs.

s/There by/Thereby/

But the above is wrong anyway because you split it into two sentences and
obfuscate the reasoning.

	 * To avoid unnecessary IPIs update only domains, which have been
         * changed by the schemata write.

That makes it clear that we do it in order to avoid the IPIs. The above
could be misinterpreted as having the side effect of avoiding the IPIs.

Thanks,

	tglx

  reply	other threads:[~2017-03-01 15:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17 19:38 [PATCH 0/5] x86/intel_rdt: Improvements/Fixes to RDT framework Vikas Shivappa
2017-02-17 19:38 ` [PATCH 1/5] x86/intel_rdt: Update control registers only when user really modifies it Vikas Shivappa
2017-03-01 13:31   ` Thomas Gleixner [this message]
2017-03-10  0:00     ` Shivappa Vikas
2017-02-17 19:38 ` [PATCH 2/5] x86/intel_rdt: Improvements to parsing schemata Vikas Shivappa
2017-03-01 14:03   ` Thomas Gleixner
2017-03-10  0:03     ` Shivappa Vikas
2017-03-10 10:53       ` Thomas Gleixner
2017-03-10 18:25         ` Shivappa Vikas
2017-03-10 18:58           ` Thomas Gleixner
2017-03-10 22:05             ` Luck, Tony
2017-03-11  7:47               ` Thomas Gleixner
2017-03-24 17:51                 ` [PATCH] x86/intel_rdt: Implement "update" mode when writing schemata file Luck, Tony
2017-03-24 23:18                   ` Fenghua Yu
2017-03-30 18:33                     ` Shivappa Vikas
2017-03-31  8:24                   ` Thomas Gleixner
2017-03-31 17:40                     ` Shivappa Vikas
2017-03-31 17:49                       ` Thomas Gleixner
2017-03-31 18:45                   ` Shivappa Vikas
2017-02-17 19:38 ` [PATCH 3/5] x86/intel_rdt: Fail early on a resource with incorrect domains Vikas Shivappa
2017-03-01 14:05   ` Thomas Gleixner
2017-02-17 19:38 ` [PATCH 4/5] x86/intel_rdt: Reset the cbm MSR during rmdir Vikas Shivappa
2017-03-01 14:11   ` Thomas Gleixner
2017-03-10  1:45     ` Shivappa Vikas
2017-02-17 19:38 ` [PATCH 5/5] x86/intel_rdt: hotcpu updates for RDT Vikas Shivappa
2017-03-01 14:24   ` Thomas Gleixner
2017-03-30 19:03     ` Shivappa Vikas

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.20.1703011412090.4005@nanos \
    --to=tglx@linutronix.de \
    --cc=andi.kleen@intel.com \
    --cc=fenghua.yu@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=tony.luck@intel.com \
    --cc=vikas.shivappa@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®