From: arne@vajhoej.dk
On 2/19/2025 10:07 PM, Dan Cross wrote:
> In article ,
> Arne Vajhøj wrote:
>> On 2/19/2025 9:26 PM, Dan Cross wrote:
>>> In article <67b66f14$0$712$14726298@news.sunsite.dk>,
>>> Arne Vajhøj wrote:
>>>> [snip]
>>>> Yes. Which becomes a little easier when restricted to a
>>>> cluster instead of any systems.
>>>
>>> I don't know what you mean when you say, "restricted to a
>>> cluster instead of any systems."
>>
>> A and B being in a cluster instead of being two
>> standalone nodes.
>
> Oh I see, you're using cluster here as a shorthand to
> mean that they're in the same administrative domain.
VMS nodes in a VMS cluster with a some common VMS cluster setup.
That does mean same administrative domain, but more than that.
>>> If you mean that this somehow
>>> makes managing state during process migration easier, then no,
>>> not really; all of the same caveats apply. For instance,
>>> if a program is using (say) a GPU for computation, part of
>>> migrating it will be extracting whatever state it has in the
>>> GPU out of the GPU, and replicating it on the destination
>>> system.
>>>
>>> At one point, the internal numbering of cores in the GPU was
>>> visible to code running on the GPU, creating an $n \choose k$
>>> fingerprinting problem for migration.
>>
>> A VMS server process will not be using GPU.
>
> Sure. GPUs, as compute accelerators, are just one example.
> It could be some other resource. The point is, process-level
> migration is not a panacea; ksplice has its place, even with
> its limitations.
Process migration would be a big huge task to implement.
But VSI are not considering the ksplice model, so I wanted to
know if they are considering the process migration model.
Arne
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
