Re: [PATCH] RTC: Add mmap method to rtc character driver

[Neil Horman <nhorman@tuxdriver.com>]

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/