WiP PVM working-set - #531
Conversation
zdave-parity
left a comment
zdave-parity
left a comment
There was a problem hiding this comment.
Still looking through this. Your changes make sense to me so far, just a few minor comments. It would be nice to merge main, think there are likely to be conflicts with the host-call changes.
| \item[$\Cepochtailstart = 500$] The number of slots into an epoch at which ticket-submission ends. See sections \ref{sec:slotkeysequence}, \ref{sec:epochmarker} and \ref{sec:safrolextandtickets}. | ||
| \item[$\Cpvmgaspagealloc = 300$] The gas cost of provisioning (and eventually deallocating) a physical frame for a \textsc{pvm} \textsc{ram} page. See appendix \ref{sec:workingsetchanges}. | ||
| \item[$\Cpvmgaspagecopy = 300$] The gas cost of populating a freshly provisioned \textsc{pvm} \textsc{ram} page from its initial image. See appendix \ref{sec:workingsetchanges}. | ||
| \item[$\Cpvmgasdeliver = 500$] The gas cost, per 1024 octets, of the eventual read-back, from the node's state or context, of data that a host-call writes into a machine's \textsc{ram}. See appendix \ref{sec:generalfunctions}. |
There was a problem hiding this comment.
This description does not make sense to me... what does it mean for data that is written to machine RAM to be eventually read from the state/context?
| \tup{\varepsilon^\phase¬fetch, \gascounter^\phase¬fetch, \workingset^\phase¬fetch} = \codepagecharge(\gascounter^\phase¬gas, \workingset^\phase¬gas, \pageforinstruction(\mathbf{c}, \mathbf{k}, \imath)) | ||
| \end{equation} | ||
|
|
||
| An instruction that resolves its target through the jump-table reads an 8-octet entry from a native jump-table, laid out at a stride of eight octets per dynamic address unit; the entry for a target address $a$ thus lies on the jump-table page $\jumppage{\floor{\nicefrac{8a}{\Cpvmpagesize}}}$, where jump-table pages $\jumptag \times \N$ form their own class of page index, distinct from the \textsc{ram} and code pages of the same machine. This read is charged like any other access. No charge arises for the special halt address (its vector is permanently resident), nor where the entry's page lies wholly beyond the table (execution panics without any table access being made), however a charge \emph{is} made for a misaligned, zero or invalid-entry target whose page is within reach of the table, as the entry must be read before it can be found invalid. Formally: |
There was a problem hiding this comment.
Using a (tag, index) tuple to identify a page in a machine makes sense but the syntax seems a bit confused here. \times is used for set product, so A \times B means { (a, b) | a \in A, b \in B }. \jumppage{x} should be (J, x) and the set of jump-table pages should be written \set{\jumptag} \times \N rather than just \jumptag \times \N.
FWIW \pageid is now essentially (machine, (tag, index)). Might make sense to flatten that to (machine, tag, index), would have to try it out to see if it made things simpler...
| &\also (g^\delta, w') = \gascostforpageaccess(w, \tup{\pid¬machine, \pid¬index}) | ||
| \end{aligned} | ||
| (\varepsilon^\phase¬mem, \gascounter^\phase¬mem, \workingset^\phase¬mem, \mem^\phase¬mem) &= A(\gascounter^\phase¬djump, \workingset^\phase¬djump, \mem, | ||
| \sqorderby{x}{\set{\build{(x, \is{r}{\top})}{x \in \mathbf{r}}} \cup \set{\build{(x, \is{r}{\bot})}{x \in \mathbf{w}}}}) \\ |
There was a problem hiding this comment.
Probably this should be something like:
\sqorderby{x}{(x, r) \in \set{\build{(x, \is{r}{\top})}{x \in \mathbf{r}}} \cup \set{\build{(x, \is{r}{\bot})}{x \in \mathbf{w}}}})
To make it really clear where the x is coming from for ordering?
| \sa¬codehash, | ||
| \is{\mathbf{\sa¬storage}}{\emset}, | ||
| \is{\mathbf{\sa¬requests}}{\set{\kv{\tup{c, l}}{\sq{}}}}, | ||
| % TODO: Should be configurable, but we're out of argument registers. Pass a pointer to struct instead? |
There was a problem hiding this comment.
You mean the initial balance should be configurable? I did have that at one point in the authority services change (#539) but ultimately dropped it as it will be possible to immediately transfer extra balance across after creation.
|
|
||
| Such an access touches the octets of its range one at a time in ascending order of address, each octet an access of its containing page. Accessibility is checked before any charge, so these charges never fault, though they may exhaust gas. | ||
|
|
||
| Should the gas run out mid-way, the result is $\oog$; the gas counter and the frames provisioned so far retain the charges already made, though no octets are written into \textsc{ram}. As $\oog$ discards the whole invocation's output, the surrounding context is immaterial and taken as its prior value. All of this is levied after the nominal $g$ of the tables below. In the descriptions that follow, the working-set argument and result are elided except where a function threads them explicitly. |
There was a problem hiding this comment.
I think we can simplify this a bit as in the case of gas exhaustion we don't keep any state changes, we basically just return "OOG" from the invoke-host-call function. The gas costs for applying any working-set changes etc can simply be added to g along with the base & linear gas costs, letting the normal gas charging logic do its thing. That is, have \wscharge¬extwrite return eg g_w for the gas costs associated with the write and stick a + g_w on the end of the g definition.
2 participants
Incomplete draft of Jan's proposed PVM working-set mechanism. I've not yet updated the host calls section, working on that now. I think the other bits are pretty much complete.
One thing I'm not sure about is how to handle the working-set size for accumulation. I've currently got that in the service state (presumably would be updated by
upgrade, this is not done yet). The reason for this is that it is needed for transfers as well as for accumulation of work-items. It would seem very awkward to require a working-set size to be specified intransfer, and if we did do something like that we would need some way to determine a single working-set size for an accumulate call which handles multiple transfers/work-items.