linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: george anzinger <george@mvista.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	<linux-kernel@vger.kernel.org>,
	William Lee Irwin III <wli@holomorphy.com>,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	"David S. Miller" <davem@redhat.com>
Subject: Re: [patch] smptimers, old BH removal, tq-cleanup, 2.5.39
Date: Tue, 1 Oct 2002 05:51:45 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0210010542240.2564-100000@localhost.localdomain> (raw)
In-Reply-To: <3D98C60B.9C1EA90B@mvista.com>


On Mon, 30 Sep 2002, george anzinger wrote:

> As the APIC timers are currently set up they are undisciplined WRT the
> PIT which is still used to drive the clock.  This means that, since this
> patch drives the "run_timer_list" code from the APIC timers, the actual
> delay in timer servicing from the requested time will vary with a.) the
> cpu (since each cpu is set up to have its timer expire at a different
> time within the 1/HZ tick) and b.) over time as the PIT and the APIC
> clocks drift.  This may be acceptable with 1/HZ timer resolution
> (however I don't really think it is), but it is in no way acceptable WRT
> high resolution timers.

the smp_processor_id()/(HZ*num_cpus) 'interleaving' of every APIC clock
was an SMP scalability issue, and it was done as part of the smptimers
patch. It just got into the kernel much earlier.

but these days, with the removal of BHs, it might be less of a factor,
mainly because timers have no global synchronization anymore, so we can
again try to not interleave the APIC clocks. Only testing will tell,
because there might be some interaction between timer-generated code
still.

Dipankar, wli, would it be possible to try the attached simple patch with
some of the more complex networking loads? The patch gets rid of the APIC
timer interleaving.

	Ingo

--- arch/i386/kernel/apic.c.orig	Tue Oct  1 05:47:34 2002
+++ arch/i386/kernel/apic.c	Tue Oct  1 05:49:23 2002
@@ -813,24 +813,9 @@
 
 static void setup_APIC_timer(unsigned int clocks)
 {
-	unsigned int slice, t0, t1;
 	unsigned long flags;
-	int delta;
 
-	local_save_flags(flags);
-	local_irq_enable();
-	/*
-	 * ok, Intel has some smart code in their APIC that knows
-	 * if a CPU was in 'hlt' lowpower mode, and this increases
-	 * its APIC arbitration priority. To avoid the external timer
-	 * IRQ APIC event being in synchron with the APIC clock we
-	 * introduce an interrupt skew to spread out timer events.
-	 *
-	 * The number of slices within a 'big' timeslice is NR_CPUS+1
-	 */
-
-	slice = clocks / (NR_CPUS+1);
-	printk("cpu: %d, clocks: %d, slice: %d\n", smp_processor_id(), clocks, slice);
+	local_irq_save(flags);
 
 	/*
 	 * Wait for IRQ0's slice:
@@ -839,22 +824,6 @@
 
 	__setup_APIC_LVTT(clocks);
 
-	t0 = apic_read(APIC_TMICT)*APIC_DIVISOR;
-	/* Wait till TMCCT gets reloaded from TMICT... */
-	do {
-		t1 = apic_read(APIC_TMCCT)*APIC_DIVISOR;
-		delta = (int)(t0 - t1 - slice*(smp_processor_id()+1));
-	} while (delta >= 0);
-	/* Now wait for our slice for real. */
-	do {
-		t1 = apic_read(APIC_TMCCT)*APIC_DIVISOR;
-		delta = (int)(t0 - t1 - slice*(smp_processor_id()+1));
-	} while (delta < 0);
-
-	__setup_APIC_LVTT(clocks);
-
-	printk("CPU%d<T0:%d,T1:%d,D:%d,S:%d,C:%d>\n", smp_processor_id(), t0, t1, delta, slice, clocks);
-
 	local_irq_restore(flags);
 }
 


  reply	other threads:[~2002-10-01  3:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-29 17:52 [patch] smptimers, old BH removal, tq-cleanup, 2.5.39 Ingo Molnar
2002-09-29 18:38 ` Jeff Garzik
2002-09-29 18:50   ` Jeff Garzik
2002-09-29 19:27   ` Ingo Molnar
2002-09-29 19:48     ` Jeff Garzik
2002-09-29 18:54 ` Dave Jones
2002-09-29 19:15 ` Dipankar Sarma
2002-09-30  0:20   ` David S. Miller
2002-09-30  4:33     ` Dipankar Sarma
2002-09-30  4:28       ` David S. Miller
2002-09-30  4:38       ` Arnaldo Carvalho de Melo
2002-09-30 12:55         ` Alan Cox
2002-09-30 14:50           ` Arnaldo Carvalho de Melo
2002-09-29 19:16 ` Ingo Molnar
2002-09-30  0:39 ` David S. Miller
2002-09-30  6:06   ` Ingo Molnar
2002-09-30 21:45 ` george anzinger
2002-10-01  3:51   ` Ingo Molnar [this message]
2002-10-01  4:18     ` David S. Miller
2002-10-01  5:24       ` Ingo Molnar
2002-10-01  8:00         ` george anzinger
2002-10-01  5:33     ` Dipankar Sarma
2002-10-03  7:10     ` Dipankar Sarma
2002-09-30 23:37 ` Christoph Hellwig
2002-09-30 16:38   ` Ingo Molnar
2002-09-30 23:45     ` Christoph Hellwig
2002-09-30 17:12       ` Ingo Molnar
2002-10-01  0:43         ` Christoph Hellwig

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=Pine.LNX.4.44.0210010542240.2564-100000@localhost.localdomain \
    --to=mingo@elte.hu \
    --cc=davem@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=george@mvista.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=wli@holomorphy.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;
as well as URLs for NNTP newsgroup(s).