Maynard Handley (name99.delete@this.name99.org) on August 24, 2018 1:26 pm wrote:
> Jeff S. (fakity.delete@this.fake.com) on August 24, 2018 12:24 pm wrote:
> > Maynard Handley (name99.delete@this.name99.org) on August 24, 2018 12:03 pm wrote:
> > > Is there a real (and realistic) fear that these instructions can generate so much heat so fast
> > > that the existing thermal tracking is too slow? And something that could be fast enough (eg
> > > as has been suggested, limiting instruction throughput at some point --- maybe issue, maybe
> > > decode) is not realistic why? Because the entire thermal modeling system runs at say 100th
> > > CPU frequency and it was too hard at the time to bolt on a new, better targeted, system?
> >
> > I have heard more concern around the input voltage sagging
> > on sudden heavy draw more than heat accumulation,
> > so maybe the thermal capacity of the die is larger in a sense than the electrical capacitance afforded by
> > the on-die and on-package systems. It seems like the 512b
> > FMA units can collectively suck down more than half
> > a core's power budget by themselves, and it might not take very many cycles of suddenly doubled (or worse)
> > power consumption to drain instantaneous power supply below the threshold of reliable operation.
> >
> > This is the kind of thing I suspect David would very succinctly summarize as "dI/dt
> > concerns", but I don't have any real data or secret sources for you unfortunately.
>
> Hmm, yeah, makes sense.
>
> It seems that, in PRINCIPLE, you should be able to monitor the charge of a capacitor over time,
> and dynamically engage in clock-by-clock throttling (through things like halting fetch, decode,
> or issue); and that this would be more performant than just clubbing the frequency?
> Of course it takes time to design a scheme like that, but this has been an issue for years...
>
> It will be interesting to see if Apple has anything along those lines in the A12. Obviously
> the details are different, but they are clearly aware that they have their own problem
> with SoC power draw possibly exceeding what an (aged) battery can supply.
> One solution to that is the Intel solution, just reducing frequency (and only improved
> over the A11 and earlier solution in that there might be more intermediate frequency steps
> available, and/or a more dynamic monitor of when current draw is going high).
> But a more performant solution would be a variant of what I've described for AVX, something that perhaps
> monitors the big capacitor rather than the battery current, and throttles on a cycle by cycle basis.

AMD seems to have an implementation of this idea:
https://www.realworldtech.com/steamroller-clocking/

I wonder if they still use it. It seemed to make a lot of sense to me at the time in terms of allowing lower voltage for the same frequency.