Improving the kernel/i386 timecounter performance
julian at elischer.org
Thu Apr 2 12:18:38 PDT 2009
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, peterjeremy at optushome.com.au wrot= :
> >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <sobomax at freebsd.org>
> >>You don't really need to =o it on every execve() unconditionally.
> >>could be done on de=and in libc, so that only when thread pass
> >>threshold, =he "common page optimization code" kicks in and does
> >>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
> >inf=rmation about its overheads in the real world. If they are
> >=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
> >=mapped by default but mapped the first time any of the information
> &=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
> 1. 3D"mailto:peterjeremy at optushome.com.au"
> 2. file://localhost/tmp/3D"m_______________________________________________
> freebsd-current at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-hackers