Re: NR_TASKS as config option.

Manfred Spraul (masp0008@stud.uni-sb.de)
Fri, 11 Jun 1999 15:12:50 +0200


Ingo wrote:
> ... FYI, i have a patch in the queue that makes nr_tasks a /proc/sys
> runtime configurable option and removes the GDT limitation in the
> x86 case. I've run a kernel with 11000 processes.

I've seen an older version of your patch, and in that version, you used
one TSS for each processor, and you copy the IO-access bitmap
around.
Is that fast enough?
Which processes usually use ioperm(), is the X-server among them?

We could also have
- 1 TSS structure for each thread
- one GDT entry for the TSS for each processor
- on task switch: we modify the GDT entry, it points to the TSS struct
of the new task.

OR:
use the IO-base address:
at system startup, 64 kb memory is allocated. One TSS for each
processor (each 100 byte) one behind each other, and the remaining
memory is used for the ioperm() bitmaps.
around 4 kB for all TSS, this means 60 kb free memory can
be addressed by the 16-bit I/O MAP BASE ADDRESS field
from every TSS.( "alloc nr"*128+4096-sizeof(TSS)*"cpu number")
First ioperm()-call: 128 bytes get allocated from this area.
on thread-switch: modify the base address
This would limit the number of ioperm()-processes to
~ 480, but that shouldn't be a real limitation.

--
    Manfred

- 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/