From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 18:48:27 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6BAA106566C; Thu, 2 Apr 2009 18:48:27 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by mx1.freebsd.org (Postfix) with ESMTP id 82A2A8FC13; Thu, 2 Apr 2009 18:48:27 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms062.mailsrvcs.net ([172.18.12.134]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHH00ED7LK4DA5R@vms173017.mailsrvcs.net>; Thu, 02 Apr 2009 13:48:04 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms062.mailsrvcs.net (Verizon Webmail) with HTTP; Thu, 02 Apr 2009 13:48:04 -0500 (CDT) Date: Thu, 02 Apr 2009 13:48:04 -0500 (CDT) From: Sergey Babkin To: peterjeremy@optushome.com.au Message-id: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Thu, 02 Apr 2009 19:07:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 18:48:28 -0000 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=