Hi Tim,

My concern is that "clock ticks" as defined by times() is pretty
unrelated to the notion of "clock ticks" in the simulator.  They're
both kind of arbitrary but that's where the similarity ends.  For
example, the value of sysconf(_SC_CLK_TCK) on the handiest Linux
system I have is 1001, while typically the simulation ticks we use are
picoseconds.

Also in an ideal world everything in the simulator would be completely
time-based, so as long as our tick resolution is good enough to
capture all of the component clock periods it shouldn't matter what
tick resolution we choose.  I'm pretty sure there are other things in
M5 now that violate this principle, but I'd prefer not to knowingly
add another one.

I'd suggest picking a semi-arbitrary but common _SC_CLK_TCK value
(like 1001, or maybe do a small survey to see what a typical range
is), then explicitly convert to that to remove the dependence on the
simulator tick rate.

Does that make sense?

To be honest, after reading the Linux times() man page, the semantics
seem flaky enough that maybe no one would notice no matter what you
did...

Steve

On Tue, Oct 6, 2009 at 4:13 AM, Timothy M Jones <[email protected]> wrote:
> Steve,
>
> Would it be possible for you to tell me what you meant by this:
>
> On Fri, 28 Aug 2009 15:23:15 +0100, Steve Reinhardt <[email protected]>
> wrote:
>>
>> - For the times patch, you should find the global
>> microseconds-per-tick value; see getrusageFunc() and getElapsedTime()
>> in syscall_emul.hh.
>>
> Do you mean I should calculate this for the return value? From the manual
> page, it says that the information returned in the struct tms and the return
> value is in clock ticks, so I shouldn't need to convert, unless I'm missing
> something. The patch is attached too so you don't have to go looking for it
> again.
>
> Thanks
> Tim
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to