From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 01:31:13 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 E1CA71065672; Tue, 31 Mar 2009 01:31:13 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC298FC08; Tue, 31 Mar 2009 01:31:13 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n2V1VBvN053678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 18:31:12 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49D1725A.1020005@FreeBSD.org> Date: Mon, 30 Mar 2009 18:31:06 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Peter Jeremy References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <20090329182219.GC38985@server.vk2pj.dyndns.org> In-Reply-To: <20090329182219.GC38985@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, David Xu , prashant.vaibhav@gmail.com Subject: 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: Tue, 31 Mar 2009 01:31:14 -0000 Peter Jeremy wrote: > On 2009-Mar-29 08:35:45 +0800, David Xu wrote: >> Julian Elischer wrote: >>> interestingly it is even feasible to have a per-thread page.. >>> it requires that the scheduler change a page table entry tough. >> I will knock his door at midnight if he added such a heavy weight >> task in the scheduler, TLB shutdown is horrible, and big code size >> squeezing out data from CPU cache is not idea model. >> scheduler should be as simple as just a context switching routine. > > If the TSC is not consistent between all cores (which is probably > the most common situation at present), then using the TSC implies > knowing which core you are executing on. From a userland perspective, > the easiest way to do this is to have a page of data that varies > depending on which core you are executing on. It's not that easy, unless you can pin thread to a specific core before reading that page. I.e. imagine the case when your thread reads per-cpu page, get preempted and scheduled to a different core, then executes RDTSC there, still thinking it got TSC reading from the first core. Even if it does re-read from that page again after reading TSC to determine if he has read the correct TSC, still it's possible (though not very likely) that it has been preempted again and scheduled to the first core after reading the TSC. -Maxim