Improving the kernel/i386 timecounter performance (GSoC proposal)

[Julian Elischer]

Hey Sergey, whatever you are using for a mail client SUCKS
real bad at the moment..

  it's really messing up your outgoing mails..

note the mail below....


Sergey Babkin wrote:
>    Apr 2, 2009 01:03:48 AM, [1]peterjeremy at optushome.com.au wrot= :
>    >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax at freebsd.org>
>    wrote:
>    >>You don't really need to =o it on every execve() unconditionally.
>    It
>    >>could be done on de=and in libc, so that only when thread pass
>    certain
>    >>threshold, =he "common page optimization code" kicks in and does
>    its
>    >>open/=map/etc magic. Otherwise, "normal" syscall is performed.
>    >
>    >Th=s "optimisation" is premature. First step is to implement an
>    >appro=ch that always maps (or whatever) the data and then gather
>    some
>    >inf=rmation about its overheads in the real world. If they are
>    deemed
>    >=xcessive, only then do we start looking at how to improve things.
>    >A=d 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
>    &=t;it is used.
>    Does it make sense to even bother with lazy mapping? =fter all, this
>    is a very minor
>    activity compared to mapping and linking=he dynamic libc. I think
>    the overhead
>    won't be even noticeable. If you=lready 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_______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"