Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Takashi Ikebe]

Rik van Riel wrote:

>On Mon, 18 Apr 2005, Takashi Ikebe wrote:
>
>  
>
>>I believe process status copy consume more time, may be below sequences are
>>needed;
>>- Stop the service on ACT-process.
>>- Copy on memory/on transaction status to shared memory.
>>    
>>
>
>No need for this, the process could ALWAYS store its
>status in a shared memory status.  This is just as
>fast as private memory, only more flexible
>  
>
I don't think so, because ACT process must stop service logic to
takeover, if the service use network listen port.(ACT process need to
stop service and close socket to take over.)

>>- Takeover shared memory key to SBY process and release the shared memory
>>- SBY process access to shared memory.
>>    
>>
>
>Which means the SBY process can attach to the shared
>memory region while the ACT process is running.  It
>can then communicate with the ACT process through a
>socket ...
>  
>
this makes software developer crazy....

>>- SBY process checks the memory and reset broken sessions.
>>- SBY process restart the service.
>>    
>>
>
>... and the SBY process can take over immediately.
>The state machine running the SBY software can
>continue using the same data structures the ACT
>process was using beforehand, since they're in a 
>shared memory region.
>  
>
>>Some part may be parallelize, but seems the more data make service 
>>disruption time longer...(It seems exceeds 100 milliseconds depends on 
>>data size..) and process will be more complicated....makes more bugs...
>>    
>>
>
>The data size should not be an issue, since the primary
>copy of the state is in the shared memory area.
>  
>
For me, is seems very dangerous to estimate the primary copy is not
broken through status takeover..

>The state machine in the SBY process can directly run
>using those data structures, so no copying is needed.
>
>The only overhead will be inter-process communication,
>having the first process close file descriptors, yielding
>the CPU to the second process, which then opens up the
>devices again.  We both know how long a context switch
>and an open() syscall take - negligable.
>
>The old version of the program can shut itself down
>after it knows the new version has taken over - in the
>background, without disrupting the now active process.
>
>  
>
I think your assumption works on some type of process, but not for all
the process.
Some process use critical resources such as fixed network listen port
can not speed up so.
More importantly, the only process who prepare to use this mechanism
only allows to use quick process takeover. This cause software
development difficult.
The live patching does not require to implement such special techniques
on applications.


-- 
Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : ikebe.takashi@xxxxxxxxxxxxx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/