>From Peter Jeremy <peterjeremy_at_optushome.com.au>, Fri, May 12, 2006 at 07:02:20PM +1000: > On Fri, 2006-May-12 10:03:22 +0200, Sten Daniel Srsdal wrote: > >How about making the scheduler insert the current time into something > >resembling in functionality of a cpu local variable (register? cache > >area?) whenever there is a context switch by the scheduler. Then > >whenever you need the current time the userland application would read > >it off this cpu local variable/holy area requiring no additional context > >switch. > > Normally, context switches occur quite frequently (my mostly idle > laptop is reporting 550-650 context switches/second whilst I type > this) - probably more so than gettimeofday() calls. Whilst this > approach saves a system call to read the time, you are probably paying > for lots more microtime() calls - which are not inexpensive on > FreeBSD. Yes doing this at the scheduler level is a mistake--at least depending on what you mean by the 'current time'. How many programs do you use that make frequent time calls? Actually not many. What we would see is an example of a horrible micro-optimization. Benchmarking the time would seem better and every other workload would be worse. > That was the main reason for my suggestion that magic page (your "cpu > local variable/holy area") be left unmapped with the microtime() call > (and other per-timeslice initialisation) occurring on the first call > to gettimeofday() in that timeslice. (Much like the npx is handled). This idea has a lot of merit. We just need to move on to something more concrete now so as to test our theory. One question is whether or not we first just make a general vsyscall as is done on linux. Can you tell me more about how npx is handled? PaulReceived on Fri May 12 2006 - 15:16:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:55 UTC