Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

   Apr 2, 2009 01:03:48 AM, [1]peterjeremy_at_optushome.com.au wrot= e:
   >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax_at_freebsd.org>
   wrote:
   >>You don't really need to = do it on every execve() unconditionally.
   It
   >>could be done on de= mand in libc, so that only when thread pass
   certain
   >>threshold, = the "common page optimization code" kicks in and does
   its
   >>open/= mmap/etc magic. Otherwise, "normal" syscall is performed.
   >
   >Th= is "optimisation" is premature. First step is to implement an
   >appro= ach that always maps (or whatever) the data and then gather
   some
   >inf= ormation about its overheads in the real world. If they are
   deemed
   >= excessive, only then do we start looking at how to improve things.
   >A= nd IMO, the first step would be to lazily map the page - so it's
   not
   >= ;mapped by default but mapped the first time any of the information
   in
   &= gt;it is used.
   Does it make sense to even bother with lazy mapping? = After all, this
   is a very minor
   activity compared to mapping and linking= the dynamic libc. I think
   the overhead
   won't be even noticeable. If you= already map 200 pages, adding one
   more should not
   make much difference.   -SB

References

   1. 3D"mailto:peterjeremy_at_optushome.com.au"
   2. file://localhost/tmp/3D"m