Date: Thu, 02 Apr 2009 13:48:04 -0500 (CDT) From: Sergey Babkin <babkin@verizon.net> To: peterjeremy@optushome.com.au Cc: sobomax@FreeBSD.org, prashant.vaibhav@gmail.com, freebsd-current@FreeBSD.org, davidxu@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net>
next in thread | raw e-mail | index | archive | help
Apr 2, 2009 01:03:48 AM, [1]peterjeremy@optushome.com.au wrot= e: >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax@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@optushome.com.au" 2. file://localhost/tmp/3D"m=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6547642.196222.1238698084570.JavaMail.root>