From: cross@spitfire.i.gajendra.net   
      
   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.   
      
   >>                               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.   
      
   >I guess as part of the migration the process would need to   
   >be non-CUR and release CPU (and GPU if VMS adds support for   
   >CUDA or similar in the future).   
   >   
   >Main memory will need to be migrated. And cluster will   
   >not help with that.   
   >   
   >But cluster with shared storage will help with disk files.   
   >   
   >And cluster with shared SYSUAF will help with identity.   
   >   
   >And cluster with shared queue database will help with jobs.   
   >   
   >> Besides, clusters can contain heterogenous systems.   
   >   
   >Yes.   
   >   
   >The nodes would need to be compatible.   
   >   
   >Mixed architecture cluster is definitely out   
   >of the question.   
   >   
   >:-)   
      
   Correct.   
      
   	- Dan C.   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)