Messages in this thread | | | From | "Manfred Spraul" <> | Subject | Re: NR_TASKS as config option. | Date | 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/
| |