From: George Anzinger <george@mvista.com>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: evan@coolrunningconcepts.com, linux-kernel@vger.kernel.org
Subject: Re: Timer idea
Date: Tue, 15 Nov 2005 11:34:26 -0800 [thread overview]
Message-ID: <437A3842.6000403@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0511151401400.6145@chaos.analogic.com>
linux-os (Dick Johnson) wrote:
> On Tue, 15 Nov 2005 evan@coolrunningconcepts.com wrote:
>
>
>>I was thinking about benchmarking, profiling, and various other applications
>>that might need frequent access to the current time. Polling timers or
>>frequent timer signal delivery both seem like there would be a lot of
>>overhead.
>>I was thinking it would be nice if you could just read the time information
>>without making an OS call.
>>
>>I figure the kernel keeps accurate records of current time information and the
>>values of various timers. I then had the idea that one could have a /dev or
>>maybe a /proc entry that would allow you to mmap() the kernel records (read
>>only) and then you could read this information right from the kernel without
>>any overhead.
>
>
> Great invention, read some timer without any overhead! I guess if
> you can figure it out you are up for a Nobel Prize, certainly a new
> breakthrough.
>
> FYI, even if you put some kernel spinning count in shared-memory,
> it would have overhead. In fact, users might even be able DOS the
> machine by spinning on that count. Putting time in /proc or /dev
> also has great overhead. Have you ever looked at how these
> file-systems work?
>
> On ix86 machines, basic time comes from chip(s), read from ports.
> That's just another tiny little problem.
Its not just shared memory, but a protected very low overhead extension of the kernel code space
into the user map. Mostly what is saved is the system call overhead.
>
> The time-keeping in Linux certainly has a few problems and they
> don't seem to be getting resolved, just exchanging one set of
> problems for another as the timer code has been rewritten many
> times. It would helpful if somebody did take a fresh new look
> at timekeeping, but reading something from shared memory just
> isn't relevant.
Possibly you would like to review what John is doing and make relevent comments.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
next prev parent reply other threads:[~2005-11-15 19:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-15 17:24 Timer idea evan
2005-11-15 18:20 ` Kenichi Okuyama
2005-11-15 18:58 ` George Anzinger
2005-11-15 19:12 ` john stultz
2005-11-15 19:13 ` linux-os (Dick Johnson)
2005-11-15 19:34 ` George Anzinger [this message]
2005-11-15 20:20 ` Christopher Friesen
2005-11-15 21:11 ` linux-os (Dick Johnson)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=437A3842.6000403@mvista.com \
--to=george@mvista.com \
--cc=evan@coolrunningconcepts.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.