mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Vikas Shivappa <vikas.shivappa@intel.com>
Cc: Vikas Shivappa <vikas.shivappa@linux.intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com,
	mingo@kernel.org, tj@kernel.org, peterz@infradead.org,
	Matt Fleming <matt.fleming@intel.com>,
	"Auld, Will" <will.auld@intel.com>,
	peter.zijlstra@intel.com, h.peter.anvin@intel.com, "Juvva,
	Kanaka D" <kanaka.d.juvva@intel.com>,
	mtosatti@redhat.com
Subject: Re: [PATCH 3/7] x86/intel_rdt: Add support for cache bit mask management
Date: Thu, 21 May 2015 02:54:26 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1505210041550.4225@nanos> (raw)
In-Reply-To: <alpine.DEB.2.11.1505202050570.4225@nanos>

On Wed, 20 May 2015, Thomas Gleixner wrote:
> On Wed, 20 May 2015, Vikas Shivappa wrote:
> > On Mon, 18 May 2015, Thomas Gleixner wrote:
> > 
> > > On Mon, 18 May 2015, Vikas Shivappa wrote:
> > > > On Fri, 15 May 2015, Thomas Gleixner wrote:
> > > > > > +static inline bool intel_rdt_update_cpumask(int cpu)
> > > > > > +{
> > > > > > +	}
> > > > > 
> > > > > You must be kidding.
> > > > 
> > > > the rapl and cqm use similar code. You want me to keep a seperate package
> > > > mask
> > > > for this code which not would be that frequent at all ?
> > > 
> > > You find for everything a place where you copied your stuff from
> > > without thinking about it, right?
> > > 
> > > Other people dessperately try to fix the cpu online times which are
> > > more and more interesting the larger the systems become. So it might
> > > be a good idea to come up with a proper fast implementation which can
> > > be used everywhere instead of blindly copying code.
> > 
> > Ok , i can try to do this as a seperate patch after the cache allocation to
> 
> Hell no. We do preparatory patches first. I'm not believing in 'can
> try' promises.
> 
> > get a support for faster implementation for traversing package and cpus in the
> > packages which can be used by everyone. we would need to start from scratch
> > with having packagemask_t equivalent to cpumask_t. hope that is fair ?
> 
> Yes, that's what I want to see.

I was kidding. You need two functionalities:

  1) A way to figure out whether you already have a CPU taking care of the
     package to which the newly online CPU belongs.

     That's something you need to track in your own code and I already
     gave you the 5 lines of code which can handle that. Remember?

        id =  topology_physical_package_id(cpu);
        if (!__test_and_set_bit(id, &package_map)) {
                cpumask_set_cpu(cpu, &rdt_cpumask);
                cbm_update_msrs(cpu);
        }

     So you cannot add much infrastructure for that because you need
     to track your own state in the CAT relevant package bitmap.

  2) A way to find out whether the to be offlined CPU is the last
     online CPU of a package. If it's not the last one, then you need
     a fast way to find the next online cpu which belongs to that
     package. If it's the last one you need to kill the cat.

     The information is already available, so it's not rocket
     science. And it takes maximal 7 lines of code to implement
     it.

     Q: Why 'maximal' 7?
     A: Because I'm a lazy bastard and cannot be bothered to figure
     	out whether one of the lines is superfluous.
     Q: Why can't I be bothered?
     A: It's none of my problems and it actually does not matter much.

     Here is the pseudo code:

     	   do_magic_stuff(tmp, TCC, COM);
	   clr(c, tmp);
	   n = do_more_stuff(tmp);
     	   if (notavailable(n))
	      	kill_the_cat();
	   else
	        set(n, RCM);

     Hint: One of the NNN placeholders resolves to topology_core_cpumask()

Now once you figured that out, you will notice that the above 5
lines of code to solve problem #1 can be simplified because you can
avoid the package_map bitmap completely.

Sorry, no pseudo code for this. But you get more than one hint this
time:
	- Hint #1 still applies
	- The logic is very similar to the above #2 pseudo code
	- It takes maximal 6 lines of code to implement it

There is one caveat:

    If Hint #1 cannot solve your problem, then you need to figure out
    why and then work with the people who are responsible for it to
    figure out how it can be resolved.

A few general hints:

    - The line counts are neither including the conditionals which
      invoke that code nor the function body nor variable
      declarations. But they include braces,

      All I care about is the logic itself. See the pseudo code
      example above.

    - Please provide a solution for #2 and #1 before you bother me
      with another patch series.

Thanks,

	tglx


     

     	       

  reply	other threads:[~2015-05-21  0:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-11 19:02 [PATCH V7 0/7] x86/intel_rdt: Intel Cache Allocation support Vikas Shivappa
2015-05-11 19:02 ` [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation detection Vikas Shivappa
2015-05-11 19:02 ` [PATCH 2/7] x86/intel_rdt: Adds support for Class of service management Vikas Shivappa
2015-05-15 19:18   ` Thomas Gleixner
2015-05-18 17:59     ` Vikas Shivappa
2015-05-18 18:41       ` Thomas Gleixner
2015-05-18 19:20         ` Borislav Petkov
2015-05-19 17:33           ` Vikas Shivappa
2015-05-19 20:35             ` Borislav Petkov
2015-05-18 19:44         ` Vikas Shivappa
2015-05-18 18:52       ` Thomas Gleixner
2015-05-18 19:27         ` Vikas Shivappa
2015-05-11 19:02 ` [PATCH 3/7] x86/intel_rdt: Add support for cache bit mask management Vikas Shivappa
2015-05-15 19:25   ` Thomas Gleixner
2015-05-18 19:17     ` Vikas Shivappa
2015-05-18 20:15       ` Thomas Gleixner
2015-05-18 21:09         ` Vikas Shivappa
2015-05-20 17:22         ` Vikas Shivappa
2015-05-20 19:02           ` Thomas Gleixner
2015-05-21  0:54             ` Thomas Gleixner [this message]
2015-05-21 16:36               ` Vikas Shivappa
2015-05-11 19:02 ` [PATCH 4/7] x86/intel_rdt: Implement scheduling support for Intel RDT Vikas Shivappa
2015-05-15 19:39   ` Thomas Gleixner
2015-05-18 18:01     ` Vikas Shivappa
2015-05-18 18:45       ` Thomas Gleixner
2015-05-18 19:18         ` Vikas Shivappa
2015-05-11 19:02 ` [PATCH 5/7] x86/intel_rdt: Software Cache for IA32_PQR_MSR Vikas Shivappa
2015-05-15 20:15   ` Thomas Gleixner
2015-05-20 17:18     ` Vikas Shivappa
2015-05-20 18:50       ` Thomas Gleixner
2015-05-20 20:43         ` Vikas Shivappa
2015-05-20 21:14           ` Thomas Gleixner
2015-05-20 22:51             ` Vikas Shivappa
2015-05-11 19:02 ` [PATCH 6/7] x86/intel_rdt: Intel haswell Cache Allocation enumeration Vikas Shivappa
2015-05-11 19:02 ` [PATCH 7/7] x86/intel_rdt: Add Cache Allocation documentation and usage guide Vikas Shivappa
2015-05-13 16:52 ` [PATCH V7 0/7] x86/intel_rdt: Intel Cache Allocation support Vikas Shivappa

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.11.1505210041550.4225@nanos \
    --to=tglx@linutronix.de \
    --cc=h.peter.anvin@intel.com \
    --cc=hpa@zytor.com \
    --cc=kanaka.d.juvva@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=mingo@kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=peter.zijlstra@intel.com \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    --cc=vikas.shivappa@intel.com \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=will.auld@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®