From: Jiri Slaby <jslaby@suse.cz>
To: Ingo Molnar <mingo@kernel.org>,
Arjan van de Ven <arjanvandeven@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jiri Kosina <jkosina@suse.cz>, Vojtech Pavlik <vojtech@suse.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Seth Jennings <sjenning@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Borislav Petkov <bp@alien8.de>,
live-patching@vger.kernel.org
Subject: Re: live kernel upgrades (was: live kernel patching design)
Date: Tue, 24 Feb 2015 13:28:48 +0100 [thread overview]
Message-ID: <54EC6E80.3040209@suse.cz> (raw)
In-Reply-To: <20150224091621.GA19976@gmail.com>
On 02/24/2015, 10:16 AM, Ingo Molnar wrote:
> and we don't design the Linux kernel for weird, extreme
> cases, we design for the common, sane case that has the
> broadest appeal, and we hope that the feature garners
> enough interest to be maintainable.
Hello,
oh, so why do we have NR_CPUS up to 8192, then? I haven't met a machine
with more than 16 cores yet. You did. But you haven't met a guy
thanksgiving for a live patching being so easy to implement, but fast. I
did.
What ones call extreme, others accept as standard. That is, I believe,
why you signed under the support for up to 8192 CPUs.
We develop Linux to be scalable, i.e. used on *whatever* scenario you
can imagine in any world. Be it large/small machines, lowmem/higmem,
numa/uma, whatever. If you don't like something, you are free to disable
that. Democracy.
> This is not a problem in general: the weird case can take
> care of itself just fine - 'specialized and weird' usually
> means there's enough money to throw at special hardware and
> human solutions or it goes extinct quickly ...
Live patching is not a random idea which is about to die. It is months
of negotiations with customers, management, between developers,
establishing teams and really thinking about the idea. The decisions
were discussed on many conferences too. I am trying to shed some light
on why we are not trying to improve criu or any other already existing
project. We studied papers, codes, implementations, kSplice and such and
decided to incline to what we have implemented, presented and merged.
thanks,
--
js
suse labs
next prev parent reply other threads:[~2015-02-24 12:28 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 18:52 [PATCH 0/3] prevent /proc/<pid>/stack garbage for running tasks Josh Poimboeuf
2015-02-16 18:52 ` [PATCH 1/3] sched: add sched_task_call() Josh Poimboeuf
2015-02-16 20:44 ` Peter Zijlstra
2015-02-16 22:05 ` Josh Poimboeuf
2015-02-17 9:24 ` Peter Zijlstra
2015-02-17 14:12 ` Josh Poimboeuf
2015-02-17 18:15 ` Peter Zijlstra
2015-02-17 21:25 ` Josh Poimboeuf
2015-02-18 15:21 ` Peter Zijlstra
2015-02-18 17:12 ` Josh Poimboeuf
2015-02-19 0:20 ` Peter Zijlstra
2015-02-19 4:17 ` Josh Poimboeuf
2015-02-19 10:16 ` Peter Zijlstra
2015-02-19 16:24 ` Josh Poimboeuf
2015-02-19 16:33 ` Vojtech Pavlik
2015-02-19 17:03 ` Josh Poimboeuf
2015-02-19 17:08 ` Jiri Kosina
2015-02-19 17:19 ` Vojtech Pavlik
2015-02-19 17:32 ` Josh Poimboeuf
2015-02-19 17:48 ` Vojtech Pavlik
2015-02-19 20:40 ` Vojtech Pavlik
2015-02-19 21:42 ` Josh Poimboeuf
2015-02-20 7:46 ` Jiri Kosina
2015-02-20 8:49 ` Jiri Kosina
2015-02-20 9:50 ` Ingo Molnar
2015-02-20 10:02 ` Jiri Kosina
2015-02-20 10:44 ` live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call()) Ingo Molnar
2015-02-20 10:58 ` Jiri Kosina
2015-02-20 19:49 ` Ingo Molnar
2015-02-20 21:46 ` Vojtech Pavlik
2015-02-20 22:08 ` Josh Poimboeuf
2015-02-21 18:30 ` Ingo Molnar
2015-02-22 8:52 ` Jiri Kosina
2015-02-22 10:17 ` Ingo Molnar
2015-02-22 19:18 ` Jiri Kosina
2015-02-23 12:43 ` Jiri Kosina
2015-02-24 10:37 ` Ingo Molnar
2015-02-21 18:18 ` Ingo Molnar
2015-02-21 18:57 ` Jiri Kosina
2015-02-21 19:16 ` Ingo Molnar
2015-02-21 19:31 ` Jiri Kosina
2015-02-21 19:48 ` Ingo Molnar
2015-02-21 20:10 ` Jiri Kosina
2015-02-21 20:53 ` Jiri Kosina
2015-02-22 8:46 ` Ingo Molnar
2015-02-22 9:08 ` Jiri Kosina
2015-02-22 9:46 ` live kernel upgrades (was: live kernel patching design) Ingo Molnar
2015-02-22 10:34 ` Ingo Molnar
2015-02-22 10:48 ` Ingo Molnar
2015-02-22 19:13 ` Jiri Kosina
2015-02-22 23:01 ` Andrew Morton
2015-02-23 0:18 ` Dave Airlie
2015-02-23 0:44 ` Arjan van de Ven
2015-02-23 8:17 ` Jiri Kosina
2015-02-23 10:42 ` Richard Weinberger
2015-02-23 11:08 ` Vojtech Pavlik
2015-02-23 11:50 ` Pavel Machek
2015-02-24 9:16 ` Ingo Molnar
2015-02-24 12:28 ` Jiri Slaby [this message]
2015-03-05 0:51 ` Ingo Molnar
2015-02-23 6:35 ` Vojtech Pavlik
2015-02-24 9:44 ` Ingo Molnar
2015-02-24 12:12 ` Vojtech Pavlik
2015-02-24 10:53 ` Ingo Molnar
2015-02-24 12:19 ` Vojtech Pavlik
2015-02-22 14:37 ` Josh Poimboeuf
2015-02-22 16:40 ` Josh Poimboeuf
2015-02-22 19:03 ` Jiri Kosina
2015-02-24 10:23 ` Ingo Molnar
2015-02-24 11:10 ` Petr Mladek
2015-02-24 12:36 ` Vojtech Pavlik
2015-02-23 11:39 ` Pavel Machek
2015-02-24 10:25 ` Ingo Molnar
2015-02-24 12:11 ` Jiri Slaby
2015-02-24 13:18 ` live kernel upgrades Pavel Emelyanov
2015-02-20 16:12 ` [PATCH 1/3] sched: add sched_task_call() Josh Poimboeuf
2015-02-20 20:08 ` Ingo Molnar
2015-02-20 21:22 ` Josh Poimboeuf
2015-02-20 17:05 ` Josh Poimboeuf
2015-02-19 21:26 ` Jiri Kosina
2015-02-19 21:38 ` Jiri Kosina
2015-02-19 23:11 ` Josh Poimboeuf
2015-02-16 18:52 ` [PATCH 2/3] stacktrace: add save_stack_trace_tsk_safe() Josh Poimboeuf
2015-02-18 0:13 ` Andrew Morton
2015-02-20 9:32 ` Jiri Kosina
2015-02-16 18:52 ` [PATCH 3/3] proc: fix /proc/<pid>/stack for running tasks Josh Poimboeuf
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=54EC6E80.3040209@suse.cz \
--to=jslaby@suse.cz \
--cc=a.p.zijlstra@chello.nl \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=arjanvandeven@gmail.com \
--cc=bp@alien8.de \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sjenning@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vojtech@suse.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