[PATCH] Hook up getcpu system call for IA64

[PATCH] Hook up getcpu system call for IA64

[Fenghua Yu]

getcpu system call returns cpu# and node# on which this system call and its caller are running. This patch hooks up its implementation on IA64.

Thanks.

-Fenghua

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>


diff -Nurp linux-2.6.git.orig/arch/ia64/kernel/entry.S linux-2.6.git/arch/ia64/kernel/entry.S
--- linux-2.6.git.orig/arch/ia64/kernel/entry.S	2007-01-26 16:41:32.000000000 -0800
+++ linux-2.6.git/arch/ia64/kernel/entry.S	2007-02-02 16:13:10.000000000 -0800
@@ -1610,5 +1610,7 @@ sys_call_table:
 	data8 sys_sync_file_range		// 1300
 	data8 sys_tee
 	data8 sys_vmsplice
+	data8 sys_ni_syscall			// reserved for move_pages
+	data8 sys_getcpu
 
 	.org sys_call_table + 8*NR_syscalls	// guard against failures to increase NR_syscalls
diff -Nurp linux-2.6.git.orig/include/asm-ia64/unistd.h linux-2.6.git/include/asm-ia64/unistd.h
--- linux-2.6.git.orig/include/asm-ia64/unistd.h	2006-11-29 12:26:15.000000000 -0800
+++ linux-2.6.git/include/asm-ia64/unistd.h	2007-02-02 15:05:27.000000000 -0800
@@ -291,11 +291,13 @@
 #define __NR_sync_file_range		1300
 #define __NR_tee			1301
 #define __NR_vmsplice			1302
+/* 1303 reserved for move_pages */
+#define __NR_getcpu			1304
 
 #ifdef __KERNEL__
 
 
-#define NR_syscalls			279 /* length of syscall table */
+#define NR_syscalls			281 /* length of syscall table */
 
 #define __ARCH_WANT_SYS_RT_SIGACTION
 

Re: [PATCH] Hook up getcpu system call for IA64

[Ken Chen]

Fenghua Yu wrote on Feb 5, 2007 4:07 PM
> getcpu system call returns cpu# and node# on which this system call
> and its caller are running. This patch hooks up its implementation on
> IA64.

I know it's trivial to wire up sys_getcpu, but please take this seriously,
it should be implemented as assembly fsys call.

- Ken

RE: [PATCH] Hook up getcpu system call for IA64

[Yu, Fenghua]

>I know it's trivial to wire up sys_getcpu, but please take this
seriously,
>it should be implemented as assembly fsys call.

Ken,

Could you please explain why fsys call? Sys_getcpu takes about 600cycles
on 1.6GHz Montecito. Do we need to save these cycles?

Thanks.

-Fenghua

RE: [PATCH] Hook up getcpu system call for IA64

[Luck, Tony]

> > getcpu system call returns cpu# and node# on which this system call
> > and its caller are running. This patch hooks up its implementation on
> > IA64.
>
> I know it's trivial to wire up sys_getcpu, but please take this seriously,
> it should be implemented as assembly fsys call.

We did look at whether it was worth doing as a fast syscall.

How often will applications call getcpu() ... I hope that they aren't doing
it hundreds of thousands of times per second (scheduler won't re-assign to
a different cpu more often than every few milli-seconds, so it is pointless
to call that often).

"Slow" syscall is ~1.5us ... which should be in the noise for what I think
is the fastest rate at which applications may call it.

Do you have some example application scenarios where you believe the
rate will be high enough to make a difference?

-Tony

Re: [PATCH] Hook up getcpu system call for IA64

[Ken Chen]

> Could you please explain why fsys call? Sys_getcpu takes about 600cycles
> on 1.6GHz Montecito. Do we need to save these cycles?

Andi Kleen used to lecture me every so often why it is important to
have fast vgetcpu on x86-64 (I don't think ia64 is excluded from
that).  His lecture is also all over the lkml mailing list.

RE: [PATCH] Hook up getcpu system call for IA64

[Luck, Tony]

> Andi Kleen used to lecture me every so often why it is important to
> have fast vgetcpu on x86-64 (I don't think ia64 is excluded from
> that).  His lecture is also all over the lkml mailing list.

I dug though that thread ... it isn't ever explicitly stated, but
it does appear that the intent is that a NUMA aware application
would use a malloc() library that called getcpu() on every memory
allocation.  If that is the usage model, then I'll agree that
getcpu() does need to be fast.

One possible way to achieve that on ia64 would be to make use of the
fact that the ar.k* registers are readable by applications, and
specifically ar.k3 contains a per-cpu value (physical address of the
kernel percpu area).  *IF* (and that is a BIG IF) we were to guarantee
to maintain ar.k3 as a per-cpu unique value, then we could implement
a very fast (even faster than fsys.S) getcpu() as:

#define __NR_getcpu                     1304

int
getcpu(unsigned *cpup, unsigned *nodep, void *cachep)
{
	static unsigned cpu = ~0, node = ~0;
	static unsigned long save_ar_k3;
	unsigned long ar_k3;

	asm volatile ("mov %0=ar.k3" : "=r" (ar_k3));
	if (cpu = ~0 || ar_k3 != save_ar_k3) {
		if (syscall(__NR_getcpu, &cpu, &node, 0) = -1)
			return -1;
		save_ar_k3 = ar_k3;
	}
	*cpup = cpu;
	*nodep = node;

	return 0;
}


Too ugly for words?  Or worth serious consideration?

-Tony

RE: [PATCH] Hook up getcpu system call for IA64

[Zou, Nanhai]

> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org
> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Luck, Tony
> Sent: 2007Äê2ÔÂ8ÈÕ 2:00
> To: Ken Chen; Yu, Fenghua
> Cc: linux-ia64@vger.kernel.org
> Subject: RE: [PATCH] Hook up getcpu system call for IA64
> 
> > Andi Kleen used to lecture me every so often why it is important to
> > have fast vgetcpu on x86-64 (I don't think ia64 is excluded from
> > that).  His lecture is also all over the lkml mailing list.
> 
> I dug though that thread ... it isn't ever explicitly stated, but
> it does appear that the intent is that a NUMA aware application
> would use a malloc() library that called getcpu() on every memory
> allocation.  If that is the usage model, then I'll agree that
> getcpu() does need to be fast.
> 
> One possible way to achieve that on ia64 would be to make use of the
> fact that the ar.k* registers are readable by applications, and
> specifically ar.k3 contains a per-cpu value (physical address of the
> kernel percpu area).  *IF* (and that is a BIG IF) we were to guarantee
> to maintain ar.k3 as a per-cpu unique value, then we could implement
> a very fast (even faster than fsys.S) getcpu() as:
> 
> #define __NR_getcpu                     1304
> 
> int
> getcpu(unsigned *cpup, unsigned *nodep, void *cachep)
> {
> 	static unsigned cpu = ~0, node = ~0;
> 	static unsigned long save_ar_k3;
> 	unsigned long ar_k3;
> 
> 	asm volatile ("mov %0=ar.k3" : "=r" (ar_k3));
> 	if (cpu = ~0 || ar_k3 != save_ar_k3) {
> 		if (syscall(__NR_getcpu, &cpu, &node, 0) = -1)
> 			return -1;
> 		save_ar_k3 = ar_k3;
> 	}
> 	*cpup = cpu;
> 	*nodep = node;
> 
> 	return 0;
> }
> 
> 
> Too ugly for words?  Or worth serious consideration?
> 
> -Tony

I think it is possible to pin ar.k3 to processor id, then change the raw_smp_processor_id() implementation.
This should be better than current raw_smp_processor_id() implementation.

Then we could implement sys_getcpu in fsys.S
That could not be very complex, only thing we need to care is exception handle in fsys code.

Thanks
Zou Nan hai

> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html