cpu-2.5.69-bk14-1

cpu-2.5.69-bk14-1

[William Lee Irwin III]

Extended cpumasks for larger systems. Now featuring bigsmp, Summit,
and Voyager updates in addition to PC-compatible, NUMA-Q, and SN2
bits from SGI.

Several minor bugfixes with improper checks of bits and some new
API pieces: cpumask_of_cpu() and cpus_promote() for replacing
1 << cpu and promoting "narrow" cpumasks (i.e. unsigned long) to
full-width, respectively.

Successfully runs on 32x NUMA-Q. Successfully compiletested on Voyager,
Summit, bigsmp, and flat logical SMP, all with typechecking. UP also
successfully compiletested with and without local APIC and IO-APIC.
Hopefully I can get my hands on another NUMA-Q quad or two soon.

vs. 2.5.69-bk14. The patch (too large to post) can be found at
ftp://ftp.kernel.org/pub/linux/kernel/people/wli/cpu/cpu-2.5.69-bk14-1.bz2

I'd be much obliged if (sub)arch maintainers could comment.

Tomita, I didn't have a way of building PC98; if you are negatively
affected somehow I'm interested in hearing of how to fix things up
or any other special handling PC98 might need here.

David & Martin, I'm not 100% sure wrt. what's going on with the IA64
pieces of the puzzle. The more I find out about what you want, the
better.

Thanks.


-- wli

Re: [Lse-tech] cpu-2.5.69-bk14-1

[Christoph Hellwig]

On Tue, May 20, 2003 at 10:03:31AM -0700, William Lee Irwin III wrote:
> Extended cpumasks for larger systems. Now featuring bigsmp, Summit,
> and Voyager updates in addition to PC-compatible, NUMA-Q, and SN2
> bits from SGI.

Here's the PPC32 UP bits.  I'll look into SMP once it starts to actually
compile again.


--- 1.26/arch/ppc/kernel/irq.c	Sun Apr 27 13:56:50 2003
+++ edited/arch/ppc/kernel/irq.c	Tue May 20 11:43:43 2003
@@ -44,6 +44,7 @@
 #include <linux/proc_fs.h>
 #include <linux/random.h>
 #include <linux/seq_file.h>
+#include <linux/cpumask.h>
 
 #include <asm/uaccess.h>
 #include <asm/bitops.h>
@@ -567,24 +568,35 @@
 #define DEFAULT_CPU_AFFINITY 0x00000001
 #endif
 
-unsigned int irq_affinity [NR_IRQS] =
-	{ [0 ... NR_IRQS-1] = DEFAULT_CPU_AFFINITY };
+#define HEX_DIGITS (2*sizeof(cpumask_t))
 
-#define HEX_DIGITS 8
+cpumask_t irq_affinity[NR_IRQS] = { [0 ... NR_IRQS-1] = CPU_MASK_ALL };
 
-static int irq_affinity_read_proc (char *page, char **start, off_t off,
+static int irq_affinity_read_proc(char *page, char **start, off_t off,
 			int count, int *eof, void *data)
 {
+	cpumask_t tmp = irq_affinity[(long)data];
+	int k, len = 0;
+
 	if (count < HEX_DIGITS+1)
 		return -EINVAL;
-	return sprintf (page, "%08x\n", irq_affinity[(int)data]);
+
+	for (k = 0; k < sizeof(cpumask_t)/sizeof(unsigned long); ++k) {
+		int j = sprintf(page, "%04hx", (u16)cpus_coerce(tmp));
+		len += j;
+		page += j;
+		cpus_shift_right(tmp, tmp, 16);
+	}
+	
+	len += sprintf(page, "\n");
+	return len;
 }
 
-static unsigned int parse_hex_value (const char *buffer,
+static unsigned int parse_hex_value(const char *buffer,
 		unsigned long count, unsigned long *ret)
 {
-	unsigned char hexnum [HEX_DIGITS];
-	unsigned long value;
+	unsigned char hexnum[HEX_DIGITS];
+	cpumask_t value = CPU_MASK_NONE;
 	int i;
 
 	if (!count)
@@ -598,10 +610,9 @@
 	 * Parse the first 8 characters as a hex string, any non-hex char
 	 * is end-of-string. '00e1', 'e1', '00E1', 'E1' are all the same.
 	 */
-	value = 0;
-
 	for (i = 0; i < count; i++) {
 		unsigned int c = hexnum[i];
+		int k;
 
 		switch (c) {
 			case '0' ... '9': c -= '0'; break;
@@ -610,18 +621,21 @@
 		default:
 			goto out;
 		}
-		value = (value << 4) | c;
+		cpus_shift_left(value, value, 4);
+		for (k = 0; k < 4; ++k)
+			if (test_bit(k, (unsigned long *)&c))
+				cpu_set(k, value);
 	}
 out:
 	*ret = value;
 	return 0;
 }
 
-static int irq_affinity_write_proc (struct file *file, const char *buffer,
+static int irq_affinity_write_proc(struct file *file, const char *buffer,
 					unsigned long count, void *data)
 {
-	int irq = (int) data, full_count = count, err;
-	unsigned long new_value;
+	int irq = (long)data, full_count = count, err;
+	cpumask_t new_value, tmp;
 
 	if (!irq_desc[irq].handler->set_affinity)
 		return -EIO;
@@ -638,29 +652,42 @@
 	 * are actually logical cpu #'s then we have no problem.
 	 *  -- Cort <cort@fsmlabs.com>
 	 */
-	if (!(new_value & cpu_online_map))
+	cpus_and(tmp, new_value, cpu_online_map);
+	if (cpus_empty(tmp))
 		return -EINVAL;
 
 	irq_affinity[irq] = new_value;
-	irq_desc[irq].handler->set_affinity(irq, new_value);
-
+	irq_desc[irq].handler->set_affinity(irq,
+			cpumask_of_cpu(first_cpu(new_value)));
 	return full_count;
 }
 
-static int prof_cpu_mask_read_proc (char *page, char **start, off_t off,
+static int prof_cpu_mask_read_proc(char *page, char **start, off_t off,
 			int count, int *eof, void *data)
 {
-	unsigned long *mask = (unsigned long *) data;
+	cpumask_t *tmp = (cpumask_t *)data;
+	int k, len = 0;
+	
 	if (count < HEX_DIGITS+1)
 		return -EINVAL;
-	return sprintf (page, "%08lx\n", *mask);
+
+	for (k = 0; k < sizeof(cpumask_t)/sizeof(unsigned long); ++k) {
+		int j = sprintf(page, "%04hx", (u16)cpus_coerce(*tmp));
+		len += j;
+		page += j;
+		cpus_shift_right(*tmp, *tmp, 16);
+	}
+
+	len += sprintf(page, "\n");
+	return len;
 }
 
 static int prof_cpu_mask_write_proc (struct file *file, const char *buffer,
 					unsigned long count, void *data)
 {
-	unsigned long *mask = (unsigned long *) data, full_count = count, err;
-	unsigned long new_value;
+	cpumask_t *mask = (cpumask_t *)data;
+	unsigned long full_count = count, err;
+	cpumask_t new_value;
 
 	err = parse_hex_value(buffer, count, &new_value);
 	if (err)

Re: [Lse-tech] cpu-2.5.69-bk14-1

[Martin J. Bligh]

> Extended cpumasks for larger systems. Now featuring bigsmp, Summit,
> and Voyager updates in addition to PC-compatible, NUMA-Q, and SN2
> bits from SGI.

Can you remove the random cleanups from this, and just leave the actual
patch please? Things like:

 static inline int apic_id_registered(void)
 {
-       return (1);
+       return 1;
 }
 
... have sweet FA to do with this. If you want to do that, it's a separate
patch.

M.

Re: [Lse-tech] cpu-2.5.69-bk14-1

[William Lee Irwin III]

On Tue, May 20, 2003 at 10:03:31AM -0700, William Lee Irwin III wrote:
>> Extended cpumasks for larger systems. Now featuring bigsmp, Summit,
>> and Voyager updates in addition to PC-compatible, NUMA-Q, and SN2
>> bits from SGI.

On Wed, May 21, 2003 at 09:43:17AM +0100, Christoph Hellwig wrote:
> Here's the PPC32 UP bits.  I'll look into SMP once it starts to actually
> compile again.

Thanks, merged.


-- wli

Re: cpu-2.5.69-bk14-1

[Zwane Mwaikambo]

On Tue, 20 May 2003, William Lee Irwin III wrote:

> Extended cpumasks for larger systems. Now featuring bigsmp, Summit,
> and Voyager updates in addition to PC-compatible, NUMA-Q, and SN2
> bits from SGI.
> 
> Several minor bugfixes with improper checks of bits and some new
> API pieces: cpumask_of_cpu() and cpus_promote() for replacing
> 1 << cpu and promoting "narrow" cpumasks (i.e. unsigned long) to
> full-width, respectively.
> 
> Successfully runs on 32x NUMA-Q. Successfully compiletested on Voyager,
> Summit, bigsmp, and flat logical SMP, all with typechecking. UP also
> successfully compiletested with and without local APIC and IO-APIC.
> Hopefully I can get my hands on another NUMA-Q quad or two soon.

Successfully run for 4 days with various stress loads. on normally 
troublesome 3way P133 with CONFIG_NR_CPUS = 72 (255 causes a #SS with 
large .configs/kernels)

	Zwane
-- 
function.linuxpower.ca

Re: cpu-2.5.69-bk14-1

[William Lee Irwin III]

On Tue, 20 May 2003, William Lee Irwin III wrote:
> Extended cpumasks for larger systems. Now featuring bigsmp, Summit,
>> and Voyager updates in addition to PC-compatible, NUMA-Q, and SN2
>> bits from SGI.

On Sat, May 24, 2003 at 05:54:10PM -0400, Zwane Mwaikambo wrote:
> Successfully run for 4 days with various stress loads. on normally 
> troublesome 3way P133 with CONFIG_NR_CPUS = 72 (255 causes a #SS with 
> large .configs/kernels)

To clarify, this is due to bootloading limitations and kernel image size.


-- wli

Re: cpu-2.5.69-bk14-1

[Zwane Mwaikambo]

On Sat, 24 May 2003, William Lee Irwin III wrote:

> On Sat, May 24, 2003 at 05:54:10PM -0400, Zwane Mwaikambo wrote:
> > Successfully run for 4 days with various stress loads. on normally 
> > troublesome 3way P133 with CONFIG_NR_CPUS = 72 (255 causes a #SS with 
> > large .configs/kernels)
> 
> To clarify, this is due to bootloading limitations and kernel image size.

My bad, i didn't make that clear, i've seen the same with large NR_IRQS 
arrays.

	Zwane
-- 
function.linuxpower.ca