Re: CONFIG_SMP

David Luyer (luyer@ucs.uwa.edu.au)
Fri, 16 Oct 1998 16:37:09 +0800


> Is CONFIG_SMP going to be introduced into the kernel before 2.2? Now that SMP
> is well tested and supported, it'd be a shame to keep it as hidden as it was
> in 2.0

[NOTE: I use 2.0.x, however this is still relevant to 2.1.x, this
part of tasks.h and head.S have not improved]

Something else that I think would be good is making NR_TASKS and
MAX_TASKS_PER_USER configurable via config/menuconfig/xconfig,
instead of via editing the header file. At the moment I use
makefile hacks to do this;

#ifdef _DJL_NR_TASKS_
#define NR_TASKS _DJL_NR_TASKS_
#define MAX_TASKS_PER_USER 128
#else
#define NR_TASKS 512
#define MAX_TASKS_PER_USER (NR_TASKS/2)
#endif

but making MAX_TASKS_PER_USER and NR_TASKS configurable via config
would mean those (like me) building dozens of kernels from one source
tree don't have to edit either tasks.h or some hacked makefile each
time they build a kernel for a machine with different parameters.

(note if you're doing this hack yourself: head.S needs to know the
value of NR_TASKS and doesn't get CFLAGS passed to it when compiling,
be careful in arch/i386/kernel/Makefile)

David.

PS: I have a heap of hack-selection in my makefile, eg, remove all atime
for system, remove /dev/random support and hooks, complete destruction
of append only and immutable, something to remap the mailspool into 26
separate directories sort-of transparently to most userspace apps (except
ls :-), large fdsetsize for squid caches, etc, but most of that isn't
suitable for general consumption, just for local high-load machines.
anyway, my makefiles are so hacked up that they wouldn't be of use
to anyone else so don't ask for them if you think any of it looks
interesting :-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/