public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@osdl.org>
Cc: raybry@sgi.com, jbarnes@engr.sgi.com,
	linux-kernel@vger.kernel.org, davem@davemloft.net
Subject: Re: [profile] amortize atomic hit count increments
Date: Tue, 14 Sep 2004 00:55:44 -0700	[thread overview]
Message-ID: <20040914075544.GI9106@holomorphy.com> (raw)
In-Reply-To: <20040913235225.0fb6039b.akpm@osdl.org>

William Lee Irwin III <wli@holomorphy.com> wrote:
[...]

On Mon, Sep 13, 2004 at 11:52:25PM -0700, Andrew Morton wrote:
> A few comments which describe the design would be nice...

Okay, I'll add a few in another update. I suppose what's going on may
not be as obvious to everyone else even with the code in hand.


On Mon, Sep 13, 2004 at 11:52:25PM -0700, Andrew Morton wrote:
>>  +	local_irq_save(flags);
>>  +	per_cpu(cpu_profile_flip, cpu) = !per_cpu(cpu_profile_flip, cpu);
>>  +	local_irq_restore(flags);
>>  +	put_cpu();
>>  +}

On Mon, Sep 13, 2004 at 11:52:25PM -0700, Andrew Morton wrote:
> hm.  Does an IPI handler need to disable local IRQs?

It's for exclusion from the timer interrupt. It looks like ia32 enters
the calls with interrupts disabled, so it's probably safe to assume
it's called with disabled interrupts for all architectures (or what
architectures don't are broken by other callers elsewhere). I'll send
out an update with the explicit interrupt disablement removed.


William Lee Irwin III <wli@holomorphy.com> wrote:
>>  +	down(&profile_flip_mutex);
>>  +	j = per_cpu(cpu_profile_flip, smp_processor_id());

On Mon, Sep 13, 2004 at 11:52:25PM -0700, Andrew Morton wrote:
> Is this preempt-safe?

Yes. It's irrelevant which cpu's cpu_profile_flip is sampled. But
it's not cpu hotplug -safe, as the cpu may be offlined and the per-cpu
storage freed in the duration between calling smp_processor_id()
and dereferencing the offset from the start of the per-cpu area.
Disabling preemption while it's being sampled (no longer than that is
necessary) would repair it for cpu hotplug, as it would then have a
valid cpu (the one on which it's executing) while the flip state is
being sampled (it can't change because we own the semaphore, and won't
vary by cpu unless the on_each_cpu() is in flight, but we have to have
a valid cpu number to sample it). The cpucontrol semaphore would
be excessively heavyweight and we'd either have to conditionally
compile out the native semaphore for the cpu hotplug case or otherwise
acquire two semaphores in succession.

This raises an interesting question of how on earth for_each_online_cpu()
is handled by cpu hotplug, but I don't feel responsible for answering it.

So, my preferred fix is the following, with which I'll send out an
updated patch if everyone agrees:

Index: mm5-2.6.9-rc1/kernel/profile.c
===================================================================
--- mm5-2.6.9-rc1.orig/kernel/profile.c	2004-09-13 23:12:27.574463744 -0700
+++ mm5-2.6.9-rc1/kernel/profile.c	2004-09-14 00:10:29.820081944 -0700
@@ -209,7 +209,8 @@
 	int i, j, cpu;
 
 	down(&profile_flip_mutex);
-	j = per_cpu(cpu_profile_flip, smp_processor_id());
+	j = per_cpu(cpu_profile_flip, get_cpu());
+	put_cpu();
 	on_each_cpu(__profile_flip_buffers, NULL, 0, 1);
 	for_each_online_cpu(cpu) {
 		struct profile_hit *hits = per_cpu(cpu_profile_hits, cpu)[j];

  reply	other threads:[~2004-09-14  7:56 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-13  8:50 2.6.9-rc1-mm5 Andrew Morton
2004-09-13  9:22 ` 2.6.9-rc1-mm5 Nick Piggin
2004-09-13 17:24   ` 2.6.9-rc1-mm5 Jesse Barnes
2004-09-13 18:06     ` 2.6.9-rc1-mm5 Paul Jackson
2004-09-13 18:10       ` 2.6.9-rc1-mm5 Jesse Barnes
2004-09-13 21:30         ` 2.6.9-rc1-mm5 Jesse Barnes
2004-09-14  2:02           ` 2.6.9-rc1-mm5 Nick Piggin
2004-09-14  2:12             ` 2.6.9-rc1-mm5 Jesse Barnes
2004-09-13 10:20 ` 2.6.9-rc1-mm5 Christoph Hellwig
2004-09-13 10:48 ` 2.6.9-rc1-mm5 Rafael J. Wysocki
2004-09-13 11:13   ` 2.6.9-rc1-mm5 Nikita Danilov
2004-09-13 13:40     ` 2.6.9-rc1-mm5 Christoph Hellwig
2004-09-13 11:16   ` 2.6.9-rc1-mm5 Rafael J. Wysocki
2004-09-13 11:01 ` 2.6.9-rc1-mm5 William Lee Irwin III
2004-09-13 15:09 ` 2.6.9-rc1-mm5 Martin J. Bligh
2004-09-13 15:18   ` 2.6.9-rc1-mm5 Paul Jackson
2004-09-13 16:11     ` 2.6.9-rc1-mm5 Martin J. Bligh
2004-09-13 16:22       ` 2.6.9-rc1-mm5 Paul Jackson
2004-09-13 15:20 ` 2.6.9-rc1-mm5 Kirill Korotaev
2004-09-13 20:01   ` 2.6.9-rc1-mm5 Andrew Morton
2004-09-14  6:39     ` 2.6.9-rc1-mm5 Kirill Korotaev
2004-09-13 20:30 ` 2.6.9-rc1-mm5 Pasi Savolainen
2004-09-13 21:06 ` 2.6.9-rc1-mm5 Rafael J. Wysocki
2004-09-14  9:07   ` 2.6.9-rc1-mm5 Nikita Danilov
2004-09-14  9:12     ` 2.6.9-rc1-mm5 Andrew Morton
2004-09-14 13:21       ` 2.6.9-rc1-mm5 David Howells
2004-09-14 14:24         ` 2.6.9-rc1-mm5 James Morris
2004-09-14 15:36           ` 2.6.9-rc1-mm5 David Howells
2004-09-13 21:47 ` 2.6.9-rc1-mm5 scheduling while atomic Jesse Barnes
2004-09-13 22:56   ` Paul Jackson
2004-09-13 21:56 ` 2.6.9-rc1-mm5 bug in tcp_recvmsg? Jesse Barnes
2004-09-13 22:36   ` David S. Miller
2004-09-13 22:44     ` Jesse Barnes
2004-09-13 22:47       ` David S. Miller
2004-09-13 23:54         ` Jesse Barnes
2004-09-13 23:55           ` David S. Miller
2004-09-14  0:03             ` Jesse Barnes
2004-09-14  0:21               ` David S. Miller
2004-09-14 17:09             ` Jesse Barnes
2004-09-14  0:25 ` 2.6.9-rc1-mm5: TCP oopses James Morris
2004-09-14  2:08   ` David S. Miller
2004-09-14  3:04     ` James Morris
2004-09-14  3:34     ` Herbert Xu
2004-09-14  4:53       ` David S. Miller
2004-09-14  4:55       ` David S. Miller
2004-09-14  5:07         ` James Morris
2004-09-14  2:25 ` [pidhashing] [0/3] pid allocator updates William Lee Irwin III
2004-09-14  2:28   ` [pidhashing] [1/3] retain older vendor copyright William Lee Irwin III
2004-09-14  2:31     ` [pidhashing] [2/3] lower PID_MAX_LIMIT for 32-bit machines William Lee Irwin III
2004-09-14  2:36       ` [pidhashing] [3/3] enforce PID_MAX_LIMIT in sysctls William Lee Irwin III
2004-09-14  2:38       ` [pidhashing] [2/3] lower PID_MAX_LIMIT for 32-bit machines William Lee Irwin III
2004-09-14 10:55       ` Roger Luethi
2004-09-14 11:10         ` Lars Marowsky-Bree
2004-09-14 12:06           ` Lars Marowsky-Bree
2004-09-14 12:08           ` Roger Luethi
2004-09-14 15:41         ` William Lee Irwin III
2004-09-14 15:47           ` Roger Leuthi
2004-09-14 16:41             ` William Lee Irwin III
2004-09-14 17:16               ` Roger Luethi
2004-09-14  2:53 ` [procfs] [1/1] fix task_mmu.c text size reporting William Lee Irwin III
2004-09-14  2:54   ` William Lee Irwin III
2004-09-15 10:51     ` [procfs] [2/1] report per-process pagetable usage William Lee Irwin III
2004-09-14  4:47 ` [profile] amortize atomic hit count increments William Lee Irwin III
2004-09-14  5:05   ` David S. Miller
2004-09-14  5:32     ` William Lee Irwin III
2004-09-14  5:49       ` David S. Miller
2004-09-14  6:10         ` William Lee Irwin III
2004-09-14  6:18           ` William Lee Irwin III
2004-09-14  5:05   ` Andrew Morton
2004-09-14  5:21     ` William Lee Irwin III
2004-09-14  6:43       ` William Lee Irwin III
2004-09-14  6:52         ` Andrew Morton
2004-09-14  7:55           ` William Lee Irwin III [this message]
2004-09-14  8:48             ` William Lee Irwin III
2004-09-14 11:34   ` Andrea Arcangeli
2004-09-14 15:51     ` William Lee Irwin III
2004-09-14 16:05       ` Andrea Arcangeli
2004-09-14 16:16         ` Jesse Barnes
2004-09-14 16:31           ` Andrea Arcangeli
2004-09-14 16:45             ` William Lee Irwin III
2004-09-14 19:00           ` William Lee Irwin III
2004-09-14 19:23             ` William Lee Irwin III
2004-09-14 20:02             ` William Lee Irwin III
2004-09-14 20:04               ` William Lee Irwin III
2004-09-14 21:04                 ` William Lee Irwin III
2004-09-14 21:11                   ` William Lee Irwin III
2004-09-14 10:00 ` 2.6.9-rc1-mm5 Lorenzo Allegrucci
2004-09-15 11:36 ` 2.6.9-rc1-mm5 William Lee Irwin III
2004-09-15 11:38   ` 2.6.9-rc1-mm5 Jens Axboe
2004-09-15 12:28     ` 2.6.9-rc1-mm5 William Lee Irwin III
2004-09-15 12:41       ` 2.6.9-rc1-mm5 Jens Axboe
2004-09-15 12:50         ` 2.6.9-rc1-mm5 Jens Axboe
2004-09-15 12:53           ` 2.6.9-rc1-mm5 William Lee Irwin III
2004-09-16  0:38             ` 2.6.9-rc1-mm5 William Lee Irwin III
2004-09-16  5:44               ` 2.6.9-rc1-mm5 William Lee Irwin III
2004-09-16  5:45                 ` 2.6.9-rc1-mm5 Jens Axboe

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=20040914075544.GI9106@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=jbarnes@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raybry@sgi.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