lkml.org 
[lkml]   [1999]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Per-Processor Data Page
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.055 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site