Athlon-SMP compiles & runs. inline fns honored.
Subsystems (3)
PATCH 1/1 Athlon-SMP compiles & runs. inline fns honored.
Hi Alan
I found one way to break the circularity. The association of type and struct definitions with interlocking inline functions caused the problem. This extracts task_struct from linux/sched.h to its own header, linux/task_struct.h. There are a few modifications elsewhere to support this. I'm not sure all the changes were necessary, but they are working as I write:
$ uname -a Linux mercury 2.4.1 #3 SMP Sat Feb 10 08:28:39 EST 2001 i686 unknown $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping : 2 cpu MHz : 704.949 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow bogomips : 1405.74
I don't have access to a real SMP Athlon box, so I'd appreciate test reports on the real thing. I expect some polishing will be needed.
Cheers,
Tom
Signature · 1 line
The Daemons lurk and are dumb. -- Emerson
include/asm-i386/string.h +2 -3
@@ -289,10 +289,9 @@/* All this just for in_interrupt() ... */ -#include <asm/system.h> -#include <asm/ptrace.h> +#include <linux/task_struct.h> +#include <asm/current.h> #include <linux/smp.h> -#include <linux/spinlock.h> #include <linux/interrupt.h> #include <asm/mmx.h>
include/linux/capability.h +2 -0
@@ -14,7 +14,9 @@#define _LINUX_CAPABILITY_H#include <linux/types.h> +/* Try removing -- we'll see if there are parasitic users #include <linux/fs.h> +*/ /* User-level do most of the mapping between kernel and user capabilities based on the version tag given by the kernel. The
include/linux/mm_struct.h +47 -0
47 lines not on this page · raw message
include/linux/sched.h +3 -145
166 lines not on this page · raw message
include/linux/signal.h +1 -4
@@ -14,10 +14,7 @@siginfo_t info; }; -struct sigpending { -struct sigqueue *head, **tail; -sigset_t signal; -}; +#include <linux/sigpending.h> /* * Define some primitives to manipulate sigset_t.
include/linux/sigpending.h +19 -0
@@ -0,0 +1,19 @@ +#ifndef _LINUX_SIGPENDING_H +#define _LINUX_SIGPENDING_H + +#include <asm/signal.h> + +#ifdef __KERNEL__ + +#ifndef _LINUX_SIGNAL_H +struct sigqueue ; +#endif + +struct sigpending { +struct sigqueue *head, **tail; +sigset_t signal; +}; + +#endif /* __KERNEL__ */ + +#endif /* _LINUX_SIGPENDING_H */
include/linux/task_struct.h +212 -0
212 lines not on this page · raw message
include/linux/mm_struct.h line 20
Quoted 6 lines · Tom Leete
include/linux/mm_struct.h +5
-0+ +#ifndef _LINUX_MM_H +struct vm_area_struct ; +#endif +
Are the #ifndef's necessary?
Could you try to remove the #ifndef and always declare the struct? gcc shouldn't complain.
include/linux/task_struct.h line 82
Quoted 9 lines
include/linux/task_struct.h +9
-0+ +/* Try removing /linux/fs.h in capability.h first +#ifndef _LINUX_CAPABILITY_H +typedef struct bogus_cap_struct { +__u32 cap; +} kernel_cap_t; +#endif +*/ +
Is is possible to get rid of that one?
What if somone modifies capability.h?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines · Manfred Spraul
include/linux/mm_struct.h line 20
Quoted 6 lines · Tom Leete
include/linux/mm_struct.h +5
-0+ +#ifndef _LINUX_MM_H +struct vm_area_struct ; +#endif +Are the #ifndef's necessary?
Could you try to remove the #ifndef and always declare the struct? gcc shouldn't complain.
Probably not necessary, but that seemed tidier if the struct definition is available.
Quoted 12 lines
include/linux/task_struct.h line 82
Quoted 10 lines
include/linux/task_struct.h +9
-0+ +/* Try removing /linux/fs.h in capability.h first +#ifndef _LINUX_CAPABILITY_H +typedef struct bogus_cap_struct { +__u32 cap; +} kernel_cap_t; +#endif +*/ +Is is possible to get rid of that one?
What if somone modifiescapability.h?
Yes, that's provisional and is superfluous if 'capability.h:17 #include <linux/fs.h>' is to be removed. It is commented out in the preliminary patch. Awaiting comment from the authors.
Quoted 3 lines
--
Manfred
After critique is in, I'll make a polished final version.
Thanks for the review,
Tom
Signature · 5 lines
The Daemons lurk and are dumb. -- Emerson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Tom Leete
Hi Alan
I found one way to break the circularity. The association of type and struct definitions with interlocking inline functions caused the problem. This extracts
task_structfromlinux/sched.hto its own header,linux/task_struct.h. There are a few modifications elsewhere to support this. I'm not sure all the changes were necessary, but they are working as I write:
[long patch snipped]
Ouch. What about un-inlining in_interrupt() for all SMP cases? Reduces code size just a bit, and function calls aren't very expensive on SMP machines IMHO... (and as a side effect solves this problem...)
Jeff
Signature · 7 lines
Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines
Ouch. What about un-inlining
in_interrupt()for all SMP cases? Reduces code size just a bit, and function calls aren't very expensive on SMP machines IMHO... (and as a side effect solves this problem...)
Call, conditional branch, call is pretty expensive and thats what most in_interrupt and small constant memcpy/memset paths are
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/