From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Erich Focht <efocht@ess.nec.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: LSE <lse-tech@lists.sourceforge.net>, Ingo Molnar <mingo@elte.hu>,
Michael Hohnbaum <hohnbaum@us.ibm.com>
Subject: Re: [Lse-tech] [PATCH 1/2] node affine NUMA scheduler
Date: Sun, 22 Sep 2002 08:52:31 -0700 [thread overview]
Message-ID: <73440311.1032684750@[10.10.2.3]> (raw)
In-Reply-To: <200209211159.41751.efocht@ess.nec.de>
A few comments ... mainly just i386 arch things (which aren't
really your fault, was just a lack of the mechanisms being in
mainline), and a request to push a couple of things down into
the arch trees from rearing their ugly head into generic code ;-)
M.
> +static int __initdata nr_lnodes = 0;
> +
Use numnodes.
> cpu = ++cpucount;
> +#ifdef CONFIG_NUMA_SCHED
> + cell = SAPICID_TO_PNODE(apicid);
> + if (pnode_to_lnode[cell] < 0) {
> + pnode_to_lnode[cell] = nr_lnodes++;
> + }
> +#endif
pnodes and lnodes are all 1-1, so they're just called nodes for
i386, and there's no such thing as a SAPICID on this platform.
> /*
> * We can't use kernel_thread since we must avoid to
> * reschedule the child.
> @@ -996,6 +1004,10 @@ static void __init smp_boot_cpus(unsigne
> set_bit(0, &cpu_callout_map);
> boot_cpu_logical_apicid = logical_smp_processor_id();
> map_cpu_to_boot_apicid(0, boot_cpu_apicid);
> +#ifdef CONFIG_NUMA_SCHED
> + pnode_to_lnode[SAPICID_TO_PNODE(boot_cpu_apicid)] = nr_lnodes++;
> + printk("boot_cpu_apicid = %d, nr_lnodes = %d, lnode = %d\n", boot_cpu_apicid, nr_lnodes, pnode_to_lnode[0]);
> +#endif
Ditto. All these mappings exist already. No need to reinvent them.
The -mm tree has a generic cpu_to_node macro, which keys off the
logical_apic_id.
http://www.zipworld.com.au/~akpm/linux/patches/2.5/2.5.37/2.5.37-mm1/broken-out/topology-api.patch
> +#ifdef CONFIG_NUMA_SCHED
> +#define NR_NODES 8
MAX_NUMNODES exists for every arch (except maybe ia64 ;-))
> +#define cpu_physical_id(cpuid) (cpu_to_physical_apicid(cpuid))
Not needed, should be buried within a wrapper, not exposed to
generic code.
> +#define SAPICID_TO_PNODE(hwid) (hwid >> 4)
Grrr. No such thing.
> diff -urNp a/include/linux/sched.h b/include/linux/sched.h
> +extern int pnode_to_lnode[NR_NODES];
> +extern char lnode_number[NR_CPUS] __cacheline_aligned;
Can't you push all this down into the arch ....
> +#define CPU_TO_NODE(cpu) lnode_number[cpu]
... by letting them define cpu_to_node() themselves?
(most people don't have lnodes and pnodes, etc).
> +EXPORT_SYMBOL(runqueues_address);
> +EXPORT_SYMBOL(numpools);
> +EXPORT_SYMBOL(pool_ptr);
> +EXPORT_SYMBOL(pool_cpus);
> +EXPORT_SYMBOL(pool_nr_cpus);
> +EXPORT_SYMBOL(pool_mask);
> +EXPORT_SYMBOL(sched_migrate_task);
Aren't these internal scheduler things?
> diff -urNp a/kernel/sched.c b/kernel/sched.c
> +int pnode_to_lnode[NR_NODES] = { [0 ... NR_NODES-1] = -1 };
> +char lnode_number[NR_CPUS] __cacheline_aligned;
Ditto.
> + int this_pool = CPU_TO_NODE(this_cpu);
> + int this_pool=CPU_TO_NODE(this_cpu), weight, maxweight=0;
Howcome you can use the CPU_TO_NODE abstraction here ...
> + /* build translation table for CPU_TO_NODE macro */
> + for (i = 0; i < NR_CPUS; i++)
> + if (cpu_online(i))
> + lnode_number[i] = pnode_to_lnode[SAPICID_TO_PNODE(cpu_physical_id(i))];
But not here?
next prev parent reply other threads:[~2002-09-22 15:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-21 9:59 [PATCH 1/2] node affine NUMA scheduler Erich Focht
2002-09-21 10:02 ` [PATCH 2/2] " Erich Focht
2002-09-21 15:55 ` [Lse-tech] [PATCH 1/2] " Martin J. Bligh
2002-09-21 16:32 ` Martin J. Bligh
2002-09-21 16:46 ` Martin J. Bligh
2002-09-21 17:11 ` Martin J. Bligh
2002-09-21 17:32 ` Erich Focht
2002-09-21 17:38 ` William Lee Irwin III
2002-09-21 23:18 ` William Lee Irwin III
2002-09-22 8:09 ` William Lee Irwin III
2002-09-22 8:30 ` Erich Focht
2002-09-22 17:11 ` Martin J. Bligh
2002-09-22 19:20 ` Martin J. Bligh
2002-09-22 21:59 ` Erich Focht
2002-09-22 22:36 ` William Lee Irwin III
2002-09-22 22:51 ` Martin J. Bligh
2002-09-23 18:19 ` node affine NUMA scheduler: simple benchmark Erich Focht
2002-09-22 10:35 ` [Lse-tech] [PATCH 1/2] node affine NUMA scheduler Erich Focht
2002-09-22 10:45 ` Erich Focht
2002-09-22 14:57 ` Martin J. Bligh
2002-09-23 18:38 ` Erich Focht
2002-09-23 18:47 ` Martin J. Bligh
2002-09-24 21:04 ` Erich Focht
2002-09-24 21:17 ` Martin J. Bligh
2002-09-22 15:52 ` Martin J. Bligh [this message]
2002-09-22 19:24 ` Martin J. Bligh
2002-09-24 23:59 ` Matthew Dobson
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='73440311.1032684750@[10.10.2.3]' \
--to=mbligh@aracnet.com \
--cc=efocht@ess.nec.de \
--cc=hohnbaum@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mingo@elte.hu \
/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).