Lines Matching refs:it

17 called) sets up state. Then, it enters the debugger trap, and IPIs the other
21 a CPU is derecommended due to thermal limits or otherwise, it will still be
30 in once it is done populating them. Once all CPUs are finished, they exit the
36 the scheduler and with interrupts disabled, it does not use "actual" threads to
48 finishes with its first queue, it will move on to the other.
57 Stackshot is given a fixed-size buffer upfront since it cannot allocate any
59 improved from that of singlethreaded stackshot - it uses various heuristics such
71 space, it can reach into other clusters for more.
74 originally allocated from a different cluster's buffer, it will be put into the
92 we can add it to the freelist - but this is not ideal. So, stackshot uses
113 back together into a single KCData buffer by the initiating thread, such that it
127 the error number as the data), but it's trivial to add more with the
131 easily, but for now, it can be examined in lldb with `showpcpu -V
136 During a panic stackshot, stackshot handles basically identically to how it did
144 panics, it will not be able to acquire the debugger lock since it is already
146 stackshot, it sets a flag in stackshot's state to indicate there was a panic by
150 notices it is set, it will spin in place. Before the initiating CPU spins in
151 place, it will release the debugger lock. Once all CPUs are spinning, the panic
161   estimating it once, we could estimate it for every task to further eliminate