From owner-freebsd-arch@FreeBSD.ORG Sat Jan 16 13:18:40 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D559106566C for ; Sat, 16 Jan 2010 13:18:40 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 181C68FC17 for ; Sat, 16 Jan 2010 13:18:39 +0000 (UTC) Received: by ewy26 with SMTP id 26so1790556ewy.3 for ; Sat, 16 Jan 2010 05:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=57jiny1X1IVcb6j8QPjGRuC9m4TkEInSBycs4uvD+/w=; b=LhmNZIjUa6V8WZarB5P01vHO95xHJk9eWJmT0jydfosoh6ZBRlBtdHvJYw6G9mbaHg yhcUfvKdAlD9LBgnXCPpi/Y0TNNq7a6pUwBo3lgnwTxBg9pKeP8RPkRQyiJDILYUMDB5 1/QfWCtuzcweDt9/A6eF7u1a841ZQxWfxGVAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Jb5iVq+r1xlNsml0vojETB5thzusHKbrnFO3esila4z2QoTjm5M8gPmtru+XTRpYJB mvRNANM2gFaHccSUh/pNZnEbWBvf/ODjMOQZBGDPlTqpUBBXYVLqI9I1VKJeluuI7iw/ tqhPNHZ8svLKAcOBZZ2tviQDiP/h2p1ExEwqo= MIME-Version: 1.0 Received: by 10.216.89.131 with SMTP id c3mr1286227wef.197.1263646558309; Sat, 16 Jan 2010 04:55:58 -0800 (PST) Date: Sat, 16 Jan 2010 07:55:58 -0500 Message-ID: From: "b. f." To: freebsd-arch@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: [PATCH] Statclock aliasing by LAPIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 13:18:40 -0000 >About the slowness -- I'm fine with whatever additional source to >LAPIC we would eventually use thus would you feel better if i8254 is >used replacing atrtc? ... >the new things it does introduce are secondarilly (but still: I'm fine >with whatever second source is picked up for statclock, profclock) if >you really see a concern wrt atrtc slowness. Would it be possible to to split kern.timecounter.hardware into several tunables, and make the choice of hardware (and perhaps frequency) configurable, at least to an extent, for each of the clocks? b.