Messages in this thread | | | From | Andi Kleen <> | Subject | Re: Per-Processor Data Page | From | Andi Kleen <> | Date | 09 Dec 1999 15:58:01 +0100 |
| |
slurn@griffin.engr.sgi.com (Scott Lurndal) writes: > > 5) Certain system calls such as the getpid family and gettimeofday are often > executed frequently by certain applications (for example, oracle issues > a copious number of gettimeofday calls to timestamp redo log records and > various transaction related operations), and the data could be trivally > and efficiently accessed through a user-readable per-processor data page.
I've seen gettimeofday() often as a example here in this thread for magic user process mappings, and I think that is wrong. gettimeofday() nowadays uses the CPU internal cycle counter to get very accurate timings. You would never be able to implement a counter in some memory location as accurately as the CPU does. Reading it requires some internal knowledge though (e.g. the delta between the counters on SMP systems and thus the current CPU cpu), which are better left in a system call.
For getpid alone it is not worth it IMHO (except if you want better lmbench numbers), and after that there are not many system calls left that only return simple values (you don't want to optimize uname, do you?)
> > From the standpoint of a pthreads library, when it is required to obtain the > thread private data pointer, a simple access to some fixed offset from > 0xc0001000 would suffice - likewise for the current pid, as well as the > gettimeofday[1] value.
So you want to map that page into the user space too? The problem is that you need an extra page for that: the user space threads library would need write access to the page to manage its per thread local data, but you you cannot give the user space write access to kernel pointers, thus you needed two pages for kernel information and for user space information. Also some kernel subsystems already depend on the 6+K stack, which means you cannot shrink the stack, so you just have doubled the per thread fixed non swappable memory cost from 8K to 16K.
Not good, LinuxThreads are already too costly.
But I like the idea of having some global per CPU local mapping in the kernel. It would be useful for a lot of statistics counters. E.g. networking (softnet) recently moved to smp_processor_id() indexed tables for some critical counters, but such a mapping would be better and waste less memory (less cache line alignment). It could be managed with the usual ELF segment trick similar to the cacheline aligned segment 2.3 already has.
-Andi
- 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/
| |