From: Andi Kleen <ak@muc.de>
To: Takashi Ikebe <ikebe.takashi@lab.ntt.co.jp>
Cc: Valdis.Kletnieks@vt.edu, Kyle Moffett <mrmacman_g4@mac.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Date: 26 Apr 2005 15:05:48 +0200
Date: Tue, 26 Apr 2005 15:05:47 +0200 [thread overview]
Message-ID: <20050426130547.GE65287@muc.de> (raw)
In-Reply-To: <426D9AC0.5020908@lab.ntt.co.jp>
On Tue, Apr 26, 2005 at 10:34:56AM +0900, Takashi Ikebe wrote:
> I think that's the common sense in every carrier.
> If we reboot the switch, the service will be disrupted.
> The phone network is lifeline, and does not allow to be disrupt by just
> bug fix.
> I think same kind of function is needed in many real
> enterprise/mission-critical/business area.
>
> All do with ptrace may affect target process's time critical task. (need
> to stop target process whenever fix)
Sorry, but what are your exact time requirements for this?
Remember any x86-64 CPU is really fast and it can do a _lot_ of ptrace
operations in a very short time.
Just a vague "it may be too slow" is not enough justification to
push a lot of redundant code into the kernel. Also if ptrace
should be really too slow (which I doubt, but you are welcome
to show some numbers together with real time requirements from
a real system) then we could optimize ptrace for this, e.g.
by adding a ptrace subcommand to copy whole memory blocks
more efficiently or maybe even do a mmap like thing.
But unless someone actually demonstrates this is needed it seems far overkill.
> All implement in user application costs too much, need to implement all
> the application...(and I do not know this approach really works on time
> critical applications yet.)
I think you have a lot of unproved and doubtful assumptions here.
-Andi
next prev parent reply other threads:[~2005-04-26 13:05 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-18 3:19 [PATCH x86_64] Live Patching Function on 2.6.11.7 Takashi Ikebe
2005-04-18 4:07 ` Chris Wedgwood
2005-04-18 4:19 ` Takashi Ikebe
2005-04-18 4:42 ` Daniel Jacobowitz
2005-04-18 4:55 ` Nicholas Miell
2005-04-18 5:01 ` Davide Libenzi
2005-04-18 5:41 ` Takashi Ikebe
2005-07-11 7:18 ` [PATCH] eventpoll : Suppress a short lived lock from struct file Eric Dumazet
2005-07-11 8:34 ` Peter Zijlstra
2005-07-11 9:29 ` Eric Dumazet
2005-07-11 14:00 ` Davide Libenzi
2005-07-11 15:20 ` Eric Dumazet
2005-04-18 5:00 ` [PATCH x86_64] Live Patching Function on 2.6.11.7 David S. Miller
2005-04-18 6:12 ` Chris Wedgwood
2005-04-18 6:35 ` Chris Friesen
2005-04-18 6:48 ` Chris Wedgwood
2005-04-18 10:03 ` James Courtier-Dutton
2005-04-18 9:10 ` Chris Wedgwood
2005-04-18 7:32 ` Takashi Ikebe
2005-04-18 7:56 ` Chris Wedgwood
2005-04-18 8:37 ` Takashi Ikebe
2005-04-18 8:59 ` Chris Wedgwood
2005-04-18 9:16 ` Paul Jackson
2005-04-18 9:25 ` Chris Wedgwood
2005-04-18 11:30 ` Rik van Riel
2005-04-18 12:52 ` Takashi Ikebe
2005-04-18 14:06 ` Rik van Riel
2005-04-19 2:14 ` Takashi Ikebe
2005-04-19 4:27 ` Chris Wedgwood
2005-04-19 5:19 ` Takashi Ikebe
2005-04-19 5:52 ` Chris Wedgwood
2005-04-20 4:18 ` Takashi Ikebe
2005-04-20 5:43 ` Chris Wedgwood
2005-04-20 7:35 ` Takashi Ikebe
2005-04-20 7:50 ` Chris Wedgwood
2005-04-20 7:57 ` Takashi Ikebe
2005-04-20 8:26 ` Chris Wedgwood
2005-04-20 8:45 ` Takashi Ikebe
2005-04-20 8:51 ` Chris Wedgwood
2005-04-20 11:19 ` Rik van Riel
2005-04-20 15:06 ` Chris Friesen
2005-04-20 8:34 ` Miquel van Smoorenburg
2005-04-19 5:57 ` Takashi Ikebe
2005-04-18 14:28 ` Paul Jackson
2005-04-20 13:10 ` Ralf Baechle
2005-04-20 15:08 ` Chris Friesen
2005-04-23 16:17 ` Andi Kleen
2005-04-25 2:11 ` Takashi Ikebe
2005-04-25 2:48 ` Kyle Moffett
2005-04-25 10:39 ` Takashi Ikebe
2005-04-25 11:15 ` Kyle Moffett
2005-04-25 15:09 ` Pavel Machek
2005-04-25 15:54 ` Andi Kleen
2005-04-25 16:36 ` Valdis.Kletnieks
2005-04-26 1:34 ` Takashi Ikebe
2005-04-26 2:15 ` Kyle Moffett
2005-04-26 9:36 ` Pavel Machek
2005-04-26 13:05 ` Andi Kleen [this message]
[not found] <3Uv7B-5lv-7@gated-at.bofh.it>
[not found] ` <3UvKd-5RT-1@gated-at.bofh.it>
[not found] ` <3Uw3y-65a-1@gated-at.bofh.it>
[not found] ` <3UwmX-6gm-5@gated-at.bofh.it>
[not found] ` <3UwwG-6lY-7@gated-at.bofh.it>
[not found] ` <3UwGk-6Cv-9@gated-at.bofh.it>
[not found] ` <3Uxj2-6YL-1@gated-at.bofh.it>
2005-04-18 10:59 ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050426130547.GE65287@muc.de \
--to=ak@muc.de \
--cc=Valdis.Kletnieks@vt.edu \
--cc=ikebe.takashi@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox