Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: Ksplice equivalent for VMS ?
Date: Wed, 19 Feb 2025 22:19:48 -0500
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <vp670k$2gh03$2@dont-email.me>
References: <vp4m4c$29bm9$1@dont-email.me>
 <67b66f14$0$712$14726298@news.sunsite.dk> <vp63t1$ktc$1@reader2.panix.com>
 <vp65ns$2gh03$1@dont-email.me> <vp669i$54l$1@reader2.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 20 Feb 2025 04:19:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="291f082f02d9a87e6f2e5d86182c9563";
	logging-data="2638851"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+SLItWduo069xiIAhO1yOzsS0Z0opYelU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cn7mZWIEaKOcMld+2OUrOKl9hog=
In-Reply-To: <vp669i$54l$1@reader2.panix.com>
Content-Language: en-US

On 2/19/2025 10:07 PM, Dan Cross wrote:
> In article <vp65ns$2gh03$1@dont-email.me>,
> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>> On 2/19/2025 9:26 PM, Dan Cross wrote:
>>> In article <67b66f14$0$712$14726298@news.sunsite.dk>,
>>> Arne Vajhøj  <arne@vajhoej.dk> 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