lkml.org 
[lkml]   [2005]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH x86_64] Live Patching Function on 2.6.11.7
Hello,
Rik van Riel wrote:
> On Mon, 18 Apr 2005, Chris Wedgwood wrote:
>
>>On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
>>
>>
>>>The call switching folks have been doing live patching at least
>>>since I worked on it, over 25 years ago. This is not just
>>>marketing.
>>
>>That still doesn't explain *why* live patching is needed.
>
>
> I suspect it was needed in the past, on embedded computers so
> small they could only run one program at a time.
>
> I see no reason why changing programs on the fly couldn't be
> done nicer with SHM segments today - just start up the new
> program in parallel with the old one, have it attach to the
> SHM region and handshake with the old program to take over
> operations.
>
> At that point the old program can let go of file descriptors
> (eg. those to devices), yield the CPU and the new program can
> open those file descriptors. The SHM area contains all of the
> state information needed, so the program can continue running
> like it always would.
>
> This may well be lower latency than live patching, and probably
> lower complexity/risk too...
>

I think most important thing for carrier system is service availability.
The live patch only stops process(which have 3 threads) 180 nanoseconds
with 2functions, 2 variable changes on my linux desktop(Xeon 2.8G dual).
(on sample 1)

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.
- Takeover shared memory key to SBY process and release the shared memory
- SBY process access to shared memory.
- SBY process checks the memory and reset broken sessions.
- SBY process restart the service.

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

--
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@lab.ntt.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-18 15:01    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site