Re: modeling latency (fwd)

Re: modeling latency (fwd)

[Ben Elliston]

I recently asked about modeling memory latency, which sid does not
currently accommodate.  Let's pick up the discussion on this list.


fche wrote:

[...]

"hops" are not very meaningful.  "cycles" and "time" are, and may be
converted one-to-one by some knowledgeable component.

: If so, would I be right to think aobut modelling latency by making
: the sid::bus::status type into a first-class object that components
: may manipulate as they return their status down the chain?

I would advise against making it a big object, or giving it a
complicated API.  After all, it's passed by value/copy all the time.
Also, there is no library to put the API implementation into - see
what's done in sidtypes.h (all inline functions).  (Remember to bump
up API_MAJOR_VERSION!)

[...]

So, the idea is to allow the sid::bus::status structure to return to
the caller not just an overall "ok"/"unmapped" indication, but also a
generic latency-count value (probably a 16-bit unsigned int).  This
value would originate from memory components (who would need a
configurable parameter for this), through mappers (ditto, to
optionally account for address decoding delays), through the cache
(ditto, to account for cache hit times & miss penalties), all the way
to the CPU.  (The "sid::bus::delayed" indication can finally die.)

The CPU would accumulate all the penalty cycles incoming from *all*
GETIMEM/GETMEM/SETMEM calls (well, their lower-level counterparts), in
much the same way that basic_cpu::total_insn_count is, though in a
separate counter.  Then, after the end of the step_insns() loop, this
memory latency accumulator would be converted by the CPU to
instruction-cycles units (likely through a target-specific linear
function), and pass the sum of converted memory latencies and
instruction cycles to the target scheduler in the basic_cpu::stepped()
function.

(Tracing etc. may require hanging on to these statistics beyond their
use in target scheduling, but that's a separate matter.)

Is this a plausible story & design?


- FChE

Re: modeling latency (fwd)

[Ben Elliston]

  FChE> "hops" are not very meaningful.  "cycles" and "time" are, and may be
  FChE> converted one-to-one by some knowledgeable component.

Right.

  [...]

  FChE> (ditto, to account for cache hit times & miss penalties), all the way
  FChE> to the CPU.  (The "sid::bus::delayed" indication can finally die.)

What was the intention of the delayed indication?  Current usage in
the source tree indicates that it is not quite used to model latency.
For example, the gloss component spins in a loop while the target
memory is not ready to accept a write.

Can you explain the rationale behind the origins of bus::delayed and
how you see that we can live without it?

I did not try to cover this potential change in my recent check-in.  I
felt this is a separate change that should be tacked separately.

Ben

Re: modeling latency (fwd)

[Frank Ch. Eigler]

Hi -

bje wrote:
: [...]
:   FChE> (ditto, to account for cache hit times & miss penalties), all the way
:   FChE> to the CPU.  (The "sid::bus::delayed" indication can finally die.)
: 
: What was the intention of the delayed indication?  [...]

It was to be a different way of representing bus latency.  Instead of
merely counting cycles, the bus::delayed indication was to tell the
bus master to yield to the target scheduler for a while, and try
again later.  There is some theoretical appeal, but implementing it
this way is too complicated.  For example, it would require making
all CPU memory access calls points abort/restartable; it would involve
the target scheduler a lot.  I believe some sid alumni had the same
ideas, but never got around to expressing them (and obviously to
implementing them).

IMO it can go away altogether.

BTW, regarding the proposed bus::status patch, it would be nice if you
could find some way of ensuring/requesting that the compiler packs the
struct into 4 bytes.  Maybe the g++ "enum foo : 16" extension, maybe
something else.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Mdi9VZbdDOm/ZT0RAkUIAJ9U+zgxa7u/FcThN6Hs9vcvRRZrDgCdEJ1K
9ehrlze9/q6ml8Xk28FbpKo=
=bUh0
-----END PGP SIGNATURE-----

Re: modeling latency (fwd)

[Ben Elliston]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

  Frank> BTW, regarding the proposed bus::status patch, it would be nice if you
  Frank> could find some way of ensuring/requesting that the compiler packs the
  Frank> struct into 4 bytes.  Maybe the g++ "enum foo : 16" extension, maybe
  Frank> something else.

I agree that packing the bus::status struct should be considered
important for performance, given that it is likely passed by value.

As you suggest, there is a g++ extension to help with this: packed
enums, but was never implemented.  I am testing a patch to correct
this and will hopefully submit it to gcc-patches@ this week.  It could
be quite some time before we can depend on its existence.

Ben

Re: modeling latency (fwd)

[Frank Ch. Eigler]

Hi -

bje wrote:

: [...]
: I agree that packing the bus::status struct should be considered
: important for performance, given that it is likely passed by value.

Right.

: As you suggest, there is a g++ extension to help with this: packed
: enums, but was never implemented.  [...]

There may be other relevant extensions: bitfields?

In any case, until g++ is able to help us pack this structure, you
could arrange the code to do all this, by storing the status enum
explicitly within a host_int_2 (or even host_int_1) field, accompanied
by the appropriate casts.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7NonFVZbdDOm/ZT0RAtT2AJ4xnUQoR+x/jinFDkx0QnT2nEYY4ACdGiXp
kEt4LJvjicTSxyeXpid7cfU=
=+381
-----END PGP SIGNATURE-----

Re: modeling latency (fwd)

[Ben Elliston]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

  Frank> In any case, until g++ is able to help us pack this structure, you
  Frank> could arrange the code to do all this, by storing the status enum
  Frank> explicitly within a host_int_2 (or even host_int_1) field, accompanied
  Frank> by the appropriate casts.

I've just committed a patch to do just this.

Ben