Messages in this thread | | | Date | Tue, 25 Jul 2006 15:47:33 -0400 | From | Neil Horman <> | Subject | Re: [PATCH] RTC: Add mmap method to rtc character driver |
| |
On Tue, Jul 25, 2006 at 09:31:32PM +0200, Segher Boessenkool wrote: > >>Not really. This introduces a potentially very difficult support > >>user-visible interface. Consider a tickless kernel -- you might > >>end up > >>taking tick interrupts ONLY to update this page, since you don't have > >>any way of knowing when userspace wants to look at it. > >> > >Well, you do actually know when they want to look at it. The rtc > >driver only > >unmasks its interrupt when a user space process has opened the > >device and sent > >it a RTC_UIE ON or RTC_PIE_ON (or other shuch ioctl). So if you > >open /dev/rtc, > >and memory map the page, but never enable a timer method, then > >every read of the > >page returns zero. The only overhead this patch is currently > >adding, execution > >time-wise is the extra time it takes to write to a the shared page > >variable. If > >the timer tick interrupt is executing, its because someone is > >reading tick data, > >or plans to very soon. > > But userland cannot know if there is a more efficient option to > use than this /dev/rtc way, without using VDSO/vsyscall. > Sure, but detecting if /dev/rtc via mmap is faster than gettimeofday is an orthogonal issue to having the choice in the first place. I say let the X guys write code to determine at run time what is more efficient to get their job done. I really just wanted to give them the ability to avoid making a million kernel traps a second for those arches where a userspace gettimeofday is not yet implemented, or cannot be implemented. It won't cost anything to add this feature, and if the Xorg people can write code to use gettimeofday if its faster than mmaped /dev/rtc (or even configured to do so at compile-time). This patch doesn't create any interrupts that wouldn't be generated already anyway by any user using /dev/rtc, and even if X doesn't already use /dev/rtc, the added interrupts are in trade for an equally fewer number of kernel traps, which I think has to be a net savings.
I'm not saying we shouldn't implement a vsyscall on more platforms to provide a speedup for this problem (in fact I'm interested to learn how, since I hadn't previously considered that as a possibility), but I think offering the choice is a smart thing to do until the latter solution gets propogated to other arches/platforms besides x86_64
Regards Neil
> > Segher
-- /*************************************************** *Neil Horman *Software Engineer *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu ***************************************************/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |