From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964872AbWGYVjK (ORCPT ); Tue, 25 Jul 2006 17:39:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964874AbWGYVjK (ORCPT ); Tue, 25 Jul 2006 17:39:10 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]:4318 "EHLO rwcrmhc14.comcast.net") by vger.kernel.org with ESMTP id S964872AbWGYVjJ (ORCPT ); Tue, 25 Jul 2006 17:39:09 -0400 Subject: Re: [PATCH] RTC: Add mmap method to rtc character driver From: Jim Gettys Reply-To: jg@laptop.org To: "H. Peter Anvin" Cc: Neil Horman , Dave Airlie , Segher Boessenkool , linux-kernel@vger.kernel.org, a.zummo@towertech.it, jg@freedesktop.org, Keith Packard In-Reply-To: <44C68AA8.6080702@zytor.com> References: <20060725174100.GA4608@hmsreliant.homelinux.net> <03BCDC7F-13D9-42FC-86FC-30C76FD3B3B8@kernel.crashing.org> <20060725182833.GE4608@hmsreliant.homelinux.net> <44C66C91.8090700@zytor.com> <20060725192138.GI4608@hmsreliant.homelinux.net> <20060725194733.GJ4608@hmsreliant.homelinux.net> <21d7e9970607251304n5681bf44gc751c21fd79be99d@mail.gmail.com> <44C67E1A.7050105@zytor.com> <20060725204736.GK4608@hmsreliant.homelinux.net> <1153861094.1230.20.camel@localhost.localdomain> <44C6875F.4090300@zytor.com> <1153862087.1230.38.camel@localhost.localdomain> <44C68AA8.6080702@zytor.com> Content-Type: text/plain Organization: OLPC Date: Tue, 25 Jul 2006 17:39:01 -0400 Message-Id: <1153863542.1230.41.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Keith's the expert (who wrote the smart scheduler): I'd take a wild ass guess that 10ms is good enough. Maybe people can keep him on the cc list this time... - Jim On Tue, 2006-07-25 at 14:18 -0700, H. Peter Anvin wrote: > Jim Gettys wrote: > > On Tue, 2006-07-25 at 14:04 -0700, H. Peter Anvin wrote: > > > >> That's why I'm suggesting adding a cheap, possibly low-res, gettimeofday > >> virtual system call in case there is no way for the kernel to provide > >> userspace with a cheap full-resolution gettimeofday. Obviously, if a > >> high-quality gettimeofday is available, then they can be linked together > >> by the kernel. > > > > Low res is fine: X Timestamps are 1 millisecond values, and wrap after a > > few hundred days. What we do care about is monotonically increasing > > values (until it wraps). On machines of the past, this was very > > convenient; we'd just store a 32 bit value for clients to read, and not > > bother with locking. I guess these days, you'd at least have to protect > > the store with a memory barrier, maybe.... > > > > It was amusing years ago to find toolkit bugs after applications had > > been up for that long (32 bits of milliseconds)... Yes, there are > > applications and machines that stay up that long, really there are.... > > > > Do you need 1 ms resolution, or is 10 ms good enough? > > -hpa > -- Jim Gettys One Laptop Per Child