Messages in this thread | | | Date | Fri, 18 Oct 2002 09:45:41 -0700 | From | george anzinger <> | Subject | Re: [RFC][PATCH] linux-2.5.34_vsyscall_A0 |
| |
Stephen Hemminger wrote: > > One reason gettimeofday ends up being important is that several > databases call it a lot. They use it to build up a transaction id. Under > big transaction loads, even the fast linux syscall path ends up being a > bottleneck. Also, on NUMA machines the data used for time of day (xtime) > ends up being a significant portion of the cache traffic. > > It would be great to rework the whole TSC time of day stuff to work with > per cpu data and allow unsychronized TSC's like NUMA. The problem is > that for fast user level access, there would need to be some way to find > out the current CPU and avoid preemption/migration for a short period. > It seems like the LDT stuff for per-thread data could provide the > current cpu (and maybe current pid) somehow. And it would be possible > to avoid preemption while in a vsyscall text page, some other Unix > variants do this to implement portions of the thread library in kernel > provided user text pages. > Now there is an idea! Lock preemption in user space if and only if the user is executing in a text page shared with the kernel. I have seen the need for such locking, but have always thought they were too dangerous. This convention would introduce a much higher level of security. What is left is to devise a way to let the kernel know that the preemption targeted task has left such a page so that the preemption may proceed. Possibly the kernel could plant a hint on the page that each function would check for on exit. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |