Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Rik van Riel]

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.

> - 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 ...

> - 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.

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.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
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/