mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Levon <levon@movementarian.org>
To: torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	wli@holomorphy.com, oprofile-list@lists.sf.net
Subject: [PATCH] fix oprofile on x86 > 1 counter
Date: Sun, 9 Mar 2003 15:48:42 +0000	[thread overview]
Message-ID: <20030309154841.GA19585@compsoc.man.ac.uk> (raw)


See the comment below, without this we have a choice between
dropping lots of counter events for counters > 0, or getting dazed and
confused. This brings it inline with the 2.4 module code. Tested on my 2-way.

Also fix a typo from Steven Cole, and remove some unnecessary code

please apply,
john


diff -Naur -X dontdiff linux-linus/arch/alpha/oprofile/op_model_ev4.c linux/arch/alpha/oprofile/op_model_ev4.c
--- linux-linus/arch/alpha/oprofile/op_model_ev4.c	2003-02-25 13:53:47.000000000 +0000
+++ linux/arch/alpha/oprofile/op_model_ev4.c	2003-03-08 04:31:28.000000000 +0000
@@ -34,7 +34,7 @@
 	   for these "disabled" counter overflows are ignored by the
 	   interrupt handler.
 
-	   This is most irritating, becuase the hardware *can* enable and
+	   This is most irritating, because the hardware *can* enable and
 	   disable the interrupts for these counters independently, but the
 	   wrperfmon interface doesn't allow it.  */
 
diff -Naur -X dontdiff linux-linus/arch/i386/oprofile/op_model_athlon.c linux/arch/i386/oprofile/op_model_athlon.c
--- linux-linus/arch/i386/oprofile/op_model_athlon.c	2003-02-15 18:10:37.000000000 +0000
+++ linux/arch/i386/oprofile/op_model_athlon.c	2003-03-09 13:09:00.000000000 +0000
@@ -104,10 +104,11 @@
 		if (CTR_OVERFLOWED(low)) {
 			oprofile_add_sample(eip, is_kernel, i, cpu);
 			CTR_WRITE(reset_value[i], msrs, i);
-			return 1;
 		}
 	}
-	return 0;
+
+	/* See op_model_ppro.c */
+	return 1;
 }
 
  
diff -Naur -X dontdiff linux-linus/arch/i386/oprofile/op_model_p4.c linux/arch/i386/oprofile/op_model_p4.c
--- linux-linus/arch/i386/oprofile/op_model_p4.c	2003-03-06 16:18:50.000000000 +0000
+++ linux/arch/i386/oprofile/op_model_p4.c	2003-03-09 13:08:41.000000000 +0000
@@ -608,13 +608,14 @@
  			CTR_WRITE(reset_value[i], real);
 			/* P4 quirk: you have to re-unmask the apic vector */
 			apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
-			return 1;
 		}
 	}
 
 	/* P4 quirk: you have to re-unmask the apic vector */
 	apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
-	return 0;
+
+	/* See op_model_ppro.c */
+	return 1;
 }
 
 
diff -Naur -X dontdiff linux-linus/arch/i386/oprofile/op_model_ppro.c linux/arch/i386/oprofile/op_model_ppro.c
--- linux-linus/arch/i386/oprofile/op_model_ppro.c	2003-02-15 18:10:37.000000000 +0000
+++ linux/arch/i386/oprofile/op_model_ppro.c	2003-03-09 14:15:07.000000000 +0000
@@ -98,10 +98,17 @@
 		if (CTR_OVERFLOWED(low)) {
 			oprofile_add_sample(eip, is_kernel, i, cpu);
 			CTR_WRITE(reset_value[i], msrs, i);
-			return 1;
 		}
 	}
-	return 0;
+
+	/* We can't work out if we really handled an interrupt. We
+	 * might have caught a *second* counter just after overflowing
+	 * the interrupt for this counter then arrives
+	 * and we don't find a counter that's overflowed, so we
+	 * would return 0 and get dazed + confused. Instead we always
+	 * assume we found an overflow. This sucks.
+	 */
+	return 1;
 }
 
  
diff -Naur -X dontdiff linux-linus/drivers/oprofile/cpu_buffer.c linux/drivers/oprofile/cpu_buffer.c
--- linux-linus/drivers/oprofile/cpu_buffer.c	2003-03-06 16:18:50.000000000 +0000
+++ linux/drivers/oprofile/cpu_buffer.c	2003-03-06 16:24:34.000000000 +0000
@@ -85,9 +85,6 @@
 	unsigned long head = b->head_pos;
 	unsigned long tail = b->tail_pos;
 
-	if (tail == head)
-		return b->buffer_size;
-
 	if (tail > head)
 		return tail - head;
 

                 reply	other threads:[~2003-03-09 15:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20030309154841.GA19585@compsoc.man.ac.uk \
    --to=levon@movementarian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oprofile-list@lists.sf.net \
    --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

all inboxes | Powered by JetHome®