From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 23:05:35 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 678081065679; Fri, 27 Mar 2009 23:05:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 414CB8FC1C; Fri, 27 Mar 2009 23:05:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EFE0646B53; Fri, 27 Mar 2009 19:05:34 -0400 (EDT) Date: Fri, 27 Mar 2009 23:05:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <7319.1238194922@critter.freebsd.dk> Message-ID: References: <7319.1238194922@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, 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: Fri, 27 Mar 2009 23:05:37 -0000 On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: > In message , Robert Wats > on writes: > >> I guess interesting questions are whether (a) it would be desirable to have >> per-page, per-cpu, or per-thread mappings. If there are non-synchronized >> TSCs, then there might be some interesting advantages to a per-CPU page. > > Rule #3: > The only thing worse than generalizing from one example is > generalizing from no examples at all. > > We can add those mappings when we know why we would want them. If we believe TSCs won't be synchronized, and don't want to synchronize them ourselves, then we'll need different mapping state to get from a TSC stamp to a time on different CPUs. In which case user application threads will need to know their CPU in order to use the right conversion data (ideally without a system call, since that's part of what we're avoiding here), or use a per-CPU mapping and not know (in which case they'll need to detect and handle the very rare "preempted and migrated between read TSC and read conversion data" race). I'm not pushing a per-CPU page, but there would be some interesting advantages to supporting that. Robert N M Watson Computer Laboratory University of Cambridge