mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Troy Benjegerdes <hozer@drgw.net>
To: Andi Kleen <ak@suse.de>
Cc: Mike Kravetz <mkravetz@sequent.com>,
	linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net
Subject: Re: [Lse-tech] Re: CPU affinity & IPI latency
Date: Sun, 15 Jul 2001 12:00:38 -0500	[thread overview]
Message-ID: <20010715120037.I3965@altus.drgw.net> (raw)
In-Reply-To: <20010712164017.C1150@w-mikek2.des.beaverton.ibm.com> <20010715024255.F3965@altus.drgw.net> <20010715110543.A9981@gruyere.muc.suse.de>
In-Reply-To: <20010715110543.A9981@gruyere.muc.suse.de>; from ak@suse.de on Sun, Jul 15, 2001 at 11:05:43AM +0200

On Sun, Jul 15, 2001 at 11:05:43AM +0200, Andi Kleen wrote:
> On Sun, Jul 15, 2001 at 02:42:55AM -0500, Troy Benjegerdes wrote:
> > On Thu, Jul 12, 2001 at 04:40:17PM -0700, Mike Kravetz wrote:
> > > This discussion was started on 'lse-tech@lists.sourceforge.net'.
> > > I'm widening the distribution in the hope of getting more input.
> > > 
> > > It started when Andi Kleen noticed that a single 'CPU Hog' task
> > > was being bounced back and forth between the 2 CPUs on his 2-way
> > > system.  I had seen similar behavior when running the context
> > > switching test of LMbench.  When running lat_ctx with only two
> > > threads on an 8 CPU system, one would ?expect? the two threads
> > > to be confined to two of the 8 CPUs in the system.  However, what
> > > I have observed is that the threads are effectively 'round
> > > robined' among all the CPUs and they all end up bearing
> > > an equivalent amount of the CPU load.  To more easily observe
> > > this, increase the number of 'TRIPS' in the benchmark to a really
> > > large number.
> > 
> > Did this 'CPU Hog' task do any I/O that might have caused an interrupt?
> 
> Yes; it did some IO, but most of its time was doing CPU work
> (it was CPU bound)

I shouldn't have sent that first email out so quickly. About 5 minutes 
after I sent it, I saw gzip switching CPU's with top a lot.

The next very interesting thing I found was that if I run something like 
'while true; do true; done' to load the other CPU while gzip is running, 
gzip runs faster. The time change isn't very large, and appears to be just 
barely detectable above the noise, but it definetly appears that gzip is 
bouncing back and forth between cpus if both are idle.

I'm tempted to try the somewhat brute-force approach of increasing
PROC_CHANGE_PENALTY, which is currently set to 20 (on ppc) to something
like 100. Would this be an adequate 'short-term' solution util there is 
some sort of multi-queue scheduler that everyone Linus likes? What are the 
drawbacks of increasing PROC_CHANGE_PENALTY?

> I'm not sure about the Mac, but on x86 linux boxes the SMP bootup synchronizes
> the time stamp counters of the CPUs. If they are synchronized on your box
> also you could store TSC value in the IPI sender and compute the average
> latency in the receiver. 

The PPC has a 'timebase register' which is effectively the same thing as 
the TSC, except it counts processor bus ticks/4, not cpu cycles.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Shulz

  reply	other threads:[~2001-07-15 17:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-12 23:40 Mike Kravetz
2001-07-13  0:22 ` Davide Libenzi
2001-07-13  0:36   ` Larry McVoy
2001-07-13  2:06     ` Mark Hahn
2001-07-13 16:41     ` Davide Libenzi
2001-07-13 17:31       ` Mike Kravetz
2001-07-13 19:17         ` Davide Libenzi
2001-07-13 19:39           ` [Lse-tech] " Gerrit Huizenga
2001-07-13 20:05             ` Davide Libenzi
2001-07-13 17:05     ` Mike Kravetz
2001-07-13 19:51       ` David Lang
2001-07-13 22:43         ` Mike Kravetz
2001-07-15 20:02           ` Davide Libenzi
2001-07-15 20:10             ` [Lse-tech] " Andi Kleen
2001-07-15 20:15           ` Andi Kleen
2001-07-15 20:31             ` Davide Libenzi
2001-07-16 15:46             ` [Lse-tech] " Mike Kravetz
2001-07-13 19:54       ` Chris Wedgwood
2001-07-15  7:42 ` Troy Benjegerdes
2001-07-15  9:05   ` [Lse-tech] " Andi Kleen
2001-07-15 17:00     ` Troy Benjegerdes [this message]
2001-07-16  0:58       ` Mike Kravetz
     [not found] <OF408C990D.63BC0397-ON85256A88.005CF33B@pok.ibm.com>
2001-07-13 18:27 ` Hubertus Frnake
2001-07-17 14:20 ` Hubertus Frnake
2001-07-13 20:17 Shailabh Nagar
2001-07-15 20:51 ` Davide Libenzi

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=20010715120037.I3965@altus.drgw.net \
    --to=hozer@drgw.net \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=mkravetz@sequent.com \
    /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®