Comment by 082349872349872 | Hacker News Reader

Comment by 082349872349872 | Hacker News Reader

082349872349872

So, at a SW level the equivalent to HW's "no single static scheduling works in the face of $ misses" is "no single static scheduling works in the face of blocked IO"[0], and the practical solution for the latter has proven to involve (instead of forcing the kernel to be sufficiently smart about processes' access patterns) exposing nonblocking IO to userland, why not allow the ISA to query[1] if an L1 access is currently viable (enabling dispatch to different static schedules)?

[0] on a tangent: is the fact that modern cloud development uses copious amounts of Terraform et.al., explaining what is hooked up where[2], just an epiphenomenon of Conway's law? Or is there something more fundamental driving this particular pendulum swing?

[1] sure, there may have been security concerns before, but now doesn't the Spectre family imply that adversaries can exploit the $ state anyway?

[2] resembling nothing so much as text file versions of the "system diagrams" people used to draw in the 1960's with green plastic stencils: https://americanhistory.si.edu/sites/default/files/ogmt_admi... Or would JCL cards be a closer analogy?

> why not allow the ISA to query[1] if an L1 access is currently viable

Well that's interesting. Query/branch on whether some address is presently in a given cache line, with more fun if one can test whether whether that line is exclusive/shared etc. The hardware definitely knows that, though the information may be stale immediately after providing it.

Selling that to the hardware guys would mean finding a compelling use case. I expect modifying the cache coherency implementation is done reluctantly. I can't think of one where whether a single line is resident is worth branching on, and querying whether N are present doesn't really fit the ISA model.

Further up the stack though, whether a given page is currently in memory (as opposed to swapped out) is a similar sort of thing, where one might want to prefetch it while doing other work. That might not be worth a syscall though.

So I love the suggestion but can't see the return on the silicon investment.

Not sure if the cache coherency model would need to be changed: I had been thinking of an OP like "LOAD dest, address, flag", where either dest would be loaded from address from L1, or would be set to an arbitrary value on miss (with flag being set to indicate which happened).

https://www.kernel.org/doc/Documentation/vm/pagemap.txt ?

> why not allow the ISA to query[1] if an L1 access is currently viable (enabling dispatch to different static schedules)?

For tight loops loading one or two things per iteration, maybe it'd be worth it; most other things, though, will result in code size explosion (as you'd have two paths for each load, potentially multiplying on multiple consecutive loads), and, depending on the implementation, wouldn't play well with branch prediction (though it'd be very fun to just let branch mispredictions happen, given that the check may be stale by the load time anyway).

And not everyone has given up on trying to defeat cache side-channels either - spectre didn't magically erase all reasons to want to be able to speculate loads without slow context switches.

not necessarily two per load: I was guessing that frequently all loads succeed would dispatch to a happy path and any load failing to a not-so-happy path.

(with the hopes that this might allow a software-defined rough equivalence to TFA's "An out-of-order machine starts off like the first example in early iterations, and transposes into the second example when a cache miss happens, or over many iterations of the loop if not decode limited." Or at least enough to be worthwhile given a factor of 2 power win from not using OoO?)

How temporally responsive is branch prediction these days? I'd guess there'd be a fair amount of locality, in that the $ status of one iteration's data would be highly correlated with another iteration's.

> why not allow the ISA to query[1] if an L1 access is currently viable (enabling dispatch to different static schedules)?

I guess you think of an access that is initiated, with an associated code that runs once the access is completed.

If yes, then how you save and restore a context with several queries in progress?

reasonable guess, but no: I was thinking of an access that either completes out of L1 or fails. if the software needs context, that's on it to keep.

Ok, but then what does the dev do if it fails?

It sounds like you want to use the cache as a private local memory near the core, this is called a scratchpad memory. And to maintain the scratchpad memory a DMA is usually used.

It is much more reliable than a cache that can evict data behind your back. Because we generally have no (or little) control over the cache eviction policy, and an interrupt or context switch can evict what you purposely fetch in the cache (and cache coherence can also cause data eviction).

PS: Note that in some circuits the scratchpad and the L1 cache share the same memory, this enables an adjustable cache and scratchpad size

Thanks, the existence of scratchpad (which makes the IO analogy even closer) adequately explains the lack of a non-stalling load.

Compilers which care (which would seem to be those targeting embedded; not anything gp) can then, instead of providing the two differing static schedules mentioned elsewhere in this thread, provide two different code paths: one to kick off scratchpad DMA if necessary (and possibly do something useful in the meantime?), and one that knows all its data is already in scratchpad, so it can statically unroll to an appropriate width.

Reply on news.ycombinator.com