From: William Lee Irwin III <wli@holomorphy.com>
To: Jesse Barnes <jbarnes@engr.sgi.com>
Cc: Andrea Arcangeli <andrea@novell.com>,
Andrew Morton <akpm@osdl.org>, Ray Bryant <raybry@sgi.com>,
hawkes@sgi.com, linux-kernel@vger.kernel.org,
rusty@rustcorp.com.au
Subject: Re: [profile] amortize atomic hit count increments
Date: Tue, 14 Sep 2004 12:00:30 -0700 [thread overview]
Message-ID: <20040914190030.GZ9106@holomorphy.com> (raw)
In-Reply-To: <200409140916.48786.jbarnes@engr.sgi.com>
On Tuesday, September 14, 2004 9:05 am, Andrea Arcangeli wrote:
>> Before dedicidng I'd suggest to have a look and see how the below patch
>> compares to your approch in performance terms.
On Tue, Sep 14, 2004 at 09:16:48AM -0700, Jesse Barnes wrote:
> It looks like the 512p we have here is pretty heavily reserved this week, so
> I'm not sure if I'll be able to test this (someone else might, John?). I
> think the balance we're looking for is between simplicity and
> non-brokenness. Builtin profiling is *supposed* to be simple and dumb,
> and were it not for the readprofile times, I'd say per-cpu would be
> the way to go just because it retains the simplicity of the current
> approach while allowing it to work on large machines (as well as
> limiting the performance impact of builtin profiling in general).
> wli's approach seems like a reasonable tradeoff though, assuming what
> you suggest doesn't work.
Goddamn fscking short-format VHPT crap. Rusty, how the hell do I
hotplug-ize this?
-- wli
Atop the prior per-cpu hashtable patch. It turns out that ia64 has
limitations on the sizes of per-cpu areas to the size of an area
covered by a single TLB entry, and worse yet, as short format VHPT
is being used, this TLB entry is limited to the PAGE_SIZE of the
region used for kernel data.
In order to address this, the following patch dynamically allocates
the per-cpu hashtables at boot-time. It probably needs adjustments
for cpu hotplug.
Index: mm5-2.6.9-rc1/kernel/profile.c
===================================================================
--- mm5-2.6.9-rc1.orig/kernel/profile.c 2004-09-14 01:27:49.675716672 -0700
+++ mm5-2.6.9-rc1/kernel/profile.c 2004-09-14 10:20:43.589942872 -0700
@@ -34,7 +34,7 @@
static int prof_on;
static cpumask_t prof_cpu_mask = CPU_MASK_ALL;
#ifdef CONFIG_SMP
-static DEFINE_PER_CPU(struct profile_hit [2][NR_PROFILE_HIT], cpu_profile_hits);
+static DEFINE_PER_CPU(struct profile_hit *[2], cpu_profile_hits);
static DEFINE_PER_CPU(int, cpu_profile_flip);
#endif /* CONFIG_SMP */
@@ -273,6 +273,10 @@
secondary = ~(pc << 1) & (NR_PROFILE_HIT - 1);
cpu = get_cpu();
hits = per_cpu(cpu_profile_hits, cpu)[per_cpu(cpu_profile_flip, cpu)];
+ if (!hits) {
+ put_cpu();
+ return;
+ }
local_irq_save(flags);
do {
if (hits[i].pc == pc) {
@@ -423,17 +427,58 @@
.write = write_profile,
};
+#ifdef CONFIG_SMP
+static void __init profile_nop(void *unused)
+{
+}
+#endif
+
static int __init create_proc_profile(void)
{
struct proc_dir_entry *entry;
+ int cpu;
+ (void)cpu;
if (!prof_on)
return 0;
+#ifdef CONFIG_SMP
+ for_each_online_cpu(cpu) {
+ per_cpu(cpu_profile_hits, cpu)[0]
+ = (struct profile_hit *)get_zeroed_page(GFP_KERNEL);
+ if (!per_cpu(cpu_profile_hits, cpu)[0])
+ goto out_cleanup;
+ per_cpu(cpu_profile_hits, cpu)[1]
+ = (struct profile_hit *)get_zeroed_page(GFP_KERNEL);
+ if (per_cpu(cpu_profile_hits, cpu)[1])
+ continue;
+ free_page((unsigned long)per_cpu(cpu_profile_hits, cpu)[0]);
+ goto out_cleanup;
+ }
+#endif /* CONFIG_SMP */
if (!(entry = create_proc_entry("profile", S_IWUSR | S_IRUGO, NULL)))
return 0;
entry->proc_fops = &proc_profile_operations;
entry->size = (1+prof_len) * sizeof(atomic_t);
return 0;
+#ifdef CONFIG_SMP
+out_cleanup:
+ prof_on = 0;
+ mb();
+ on_each_cpu(profile_nop, NULL, 0, 1);
+ for_each_online_cpu(cpu) {
+ unsigned long kvaddr
+ = (unsigned long)per_cpu(cpu_profile_hits, cpu)[0];
+
+ if (!kvaddr)
+ break;
+ per_cpu(cpu_profile_hits, cpu)[0] = NULL;
+ free_page(kvaddr);
+ kvaddr = (unsigned long)per_cpu(cpu_profile_hits, cpu)[1];
+ per_cpu(cpu_profile_hits, cpu)[1] = NULL;
+ free_page(kvaddr);
+ }
+ return -1;
+#endif /* CONFIG_SMP */
}
module_init(create_proc_profile);
#endif /* CONFIG_PROC_FS */
next prev parent reply other threads:[~2004-09-14 19:04 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
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 [this message]
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=20040914190030.GZ9106@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=andrea@novell.com \
--cc=hawkes@sgi.com \
--cc=jbarnes@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=raybry@sgi.com \
--cc=rusty@rustcorp.com.au \
/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