Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30781

Re: Stack analysis tool that really work?

Show all headers | View raw

On 8/7/2021 10:46 AM, Niklas Holsti wrote:
> On 2021-08-07 20:26, Don Y wrote:
>> On 8/7/2021 4:20 AM, Niklas Holsti wrote:
> 
> (In a discussion about WCET analysis more than stack analysis:)
> 
>>> Ok. If you describe your needs, perhaps I can comment.
>>
>> I'm targeting some of the bigger ARM offerings -- A53/55.  My
>> impression is they go through more "contortions" to eke out
>> additional performance than some of the smaller processors.
> 
> Out of scope for Bound-T, I'm sure. Even the AbsInt tool has no support for 
> static WCET analysis of those processors and their ARM page suggests a hybrid 
> tool instead (https://www.absint.com/ait/arm.htm).

You can see why I favor hand-waving away all of the "tricks" the processors
can play to improve performance!  Granted, the numbers that result are TRULY
"worst case" -- and likely significantly inflated!

But, if you size for that, then all of the "noncritical" stuff runs "for free"!

>>> In my experience, access to memory-mapped registers tends to be not much 
>>> slower than access to memory. Also, quite often the addresses in MMIO 
>>> accesses are static or easy to derive in static analysis, so the WCET tool 
>>> could choose the proper access time, if the tool knows enough about the 
>>> system architecture.
>>
>> Yes, that last phrase being the kicker.  Can this be simplified to something 
>> as crude as a "memory map"?
> 
> It seems so, if the access time is simply a function of the accessed address.
> 
>>> What is VMM?
>>
>> Virtual Memory Management.  I.e., when an opcode fetch (or argument 
>> reference) can not only take longer than a cache miss... but
>> *considerably* longer as the physical memory is mapped in while the
>> instruction stream "stalls".
> 
> I don't recall seeing any static WCET analysis for page faults, but there may 
> be some for Translation Look-aside Buffer misses. Out of my competence, and out 
> of scope for Bound-T, certainly.

Unlike a cache miss, it's not easy to predict those costs without an
intimate model of the software.

E.g., two "closely located" addresses can have entirely different
behaviors (timing) on a page fault.  And, you likely can't predict where
those addresses will reside as that's a function of how they are mapped
at runtime.

Unlike a conventional VMM system (faulting in/out pages from a secondary/disk
store), I rely on the mechanism heavily for communication and process container
hacks.

I.e., there's a good reason to over-specify the hardware -- so you can be
inefficient in your use of it!  :-/

>> [Note that a page fault need not map physical memory in the
>> traditional sense. It can also cause some "special" function to be
>> invoked to provide the requisite data/access.  So, the cost of a
>> fault can vary depend on *what* is faulting and which pager is
>> handling that fault]
> 
> You may be able to map some of that into a very capable schedulability 
> analyzer, one that can handle chains of "tasks" passing data/messages to each 
> other. But translating the application logic and system behaviour into a model 
> for such a schedulability analyzer is not trivial.

As my workload is dynamically defined (can grow or shrink, algorithmically),
I don't really fret this.  It's not like a closed system where what's inside
*has* to work.  If something isn't working, I can shed load (or, move it to
another processor).  And, if something is underutilized, *add* load (possibly
moved from another processor).

You typically do this intuitively on your workstation; if things start
to run sluggishly, you kill off some applications (and make a mental note
to run them, again, later).  And, if the workstation isn't "doing anything",
you *add* application processes.

If you needed to "make world", you might power up another workstation so
it didn't impede the activities of the "normal" workstation you're using.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-07-29 18:22 +0200
  Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-07-29 19:36 +0300
  Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-02 17:56 -0700
    Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-03 11:43 +0300
      Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-03 02:28 -0700
        Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 22:14 +0300
          Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 15:43 -0700
    Re: Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-08-03 11:49 +0200
      Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-03 20:17 -0700
        Re: Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-08-04 16:43 +0200
          Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 11:06 -0700
            Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 12:00 +0300
              Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 04:54 -0700
      Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 20:00 +0300
        Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 10:50 -0700
          Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 21:50 +0300
            Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 15:46 -0700
              Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 13:43 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 06:16 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 18:39 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 01:09 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-06 22:58 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 16:04 -0700
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 16:06 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 14:20 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 10:26 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 20:46 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 15:14 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 14:09 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 08:09 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 19:50 +0300
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 20:02 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 10:34 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 21:10 +0300
                Re: Stack analysis tool that really work? George Neuner <gneuner2@comcast.net> - 2021-08-06 22:55 -0400
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 13:40 +0300
                Re: Stack analysis tool that really work? George Neuner <gneuner2@comcast.net> - 2021-08-08 18:34 -0400
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-09 10:50 +0300
                Re: Stack analysis tool that really work? Paul Rubin <no.email@nospam.invalid> - 2021-08-09 11:26 -0700
                Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-09 22:59 +0300
                Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-09 12:04 -0700
          Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 13:18 +0300
            Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 04:59 -0700

csiph-web