From owner-freebsd-arch@FreeBSD.ORG Sat Jan 16 14:01:55 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 0A896106566B for ; Sat, 16 Jan 2010 14:01:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 924208FC0C for ; Sat, 16 Jan 2010 14:01:54 +0000 (UTC) Received: by fxm27 with SMTP id 27so955562fxm.3 for ; Sat, 16 Jan 2010 06:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=R1VfMQdYPHn+6QE4nxMhgWkVY0Hs58qzfUHJvzRISqI=; b=haoMQ/kxwt6n3S12/omYaNK3UbrXoM4NuiVUc70IWAR9iQLuR5uc73GkCrQJEbnCbj CBpqROxJZ7SbsZyriuh3K0MVralqxBse2PuRWpkOPYrSZ5eSOorkO5r67Fc6710d9SNU VZhpME4RFdoRfBawZK+h5zDY3Fhw1RSJ5546w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=K8o+i+BHG48z5WQCLeh2iBg7Rc3Kxk3kHbF0mSC2n5Lx0BVKwv+zen4xNs99T5cKA+ F90xxtqVihwkBF49M5XK6G4yT/OWgauCceIiHqBJZLpZzn7Gxc91gF3qBfTnnMvETPkF KIXoKDJDwefgQnTdtxOVQ7TLmx4bYe325Ef9w= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.144.208 with SMTP id a16mr764667fav.62.1263650509223; Sat, 16 Jan 2010 06:01:49 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Jan 2010 15:01:49 +0100 X-Google-Sender-Auth: 0d0d40dfcea9c9aa Message-ID: <3bbf2fe11001160601t1f488da3ud848cad7100b75d4@mail.gmail.com> From: Attilio Rao To: "b. f." Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arch@freebsd.org 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 14:01:55 -0000 2010/1/16 b. f. : >>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? I think that several things can be made. What this patch just does is to increase the flexibility of the clocks tuning and the 'loose end' is choosen by what was already happening in the old kernel. I don't think the concept is wrong per-se (we could get it being even more flexible honestly) maybe the choice of clocks is not ideal though as Bruce pointed out with his quality tests, but still falls in 'what was used before' category. Attilio -- Peace can only be achieved by understanding - A. Einstein