From: john stultz <johnstul@us.ibm.com>
To: anton wilson <anton.wilson@camotion.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: Fwd: do_gettimeofday vs. rdtsc in the scheduler
Date: 17 Sep 2002 13:29:18 -0700 [thread overview]
Message-ID: <1032294559.22815.180.camel@cog> (raw)
In-Reply-To: <200209172020.g8HKKPF13227@eng2.beaverton.ibm.com>
> I'm writing a patch for the scheduler that allows normal processes to run
> occasionally even though real-time processes completely dominate the CPU.
> In
> order to do this the way I want to for a specific real-time application, I
> need to keep track of the times that the schedule(void) function gets
> called.
> This time is then used to calculate the time difference between when a
> normal
> process was run last and the current time. I was trying to avoid
> do_gettimeofday because of the overhead, but now I'm wondering if rdtsc on
> an
> SMP machine may mess up my readings because the TSC from two different
> processors may be read. Am I right in assuming this? Secondly, any good
> suggestions on how to proceed with my patch?
Tread with caution. Some NUMA boxes do not have synced TSC, so on those
systems your code won't work. Additionally, you code would need to take
other technologies like speedstep into account as well Alternatively,
you might want to try using get_cycles, or some other semi-abstracted
interface, so alternative time sources could be used in the future
without having to re-write your code. I'm working on somewhat
abstracting out time sources with my timer-changes patch, so take a peek
at it and let me know if you have any suggestions.
thanks
-john
next parent reply other threads:[~2002-09-17 20:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200209172020.g8HKKPF13227@eng2.beaverton.ibm.com>
2002-09-17 20:29 ` john stultz [this message]
2002-09-17 20:39 ` do_gettimeofday vs. rdtsc in the scheduler David S. Miller
2002-09-17 20:57 ` john stultz
2002-09-17 20:56 ` David S. Miller
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=1032294559.22815.180.camel@cog \
--to=johnstul@us.ibm.com \
--cc=anton.wilson@camotion.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox