* Jiri Slaby wrote:
> 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.
>
>
* Jiri Slaby jsl...@suse.cz wrote:
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.
On Tue, Feb 24, 2015 at 11:23:29AM +0100, Ingo Molnar wrote:
> > Your upgrade proposal is an *enormous* disruption to the
> > system:
> >
> > - a latency of "well below 10" seconds is completely
> > unacceptable to most users who want to patch the kernel
> > of a production system _while_
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
On Tue, Feb 24, 2015 at 11:53:28AM +0100, Ingo Molnar wrote:
>
> * Jiri Kosina wrote:
>
> > [...] We could optimize the kernel the craziest way we
> > can, but hardware takes its time to reinitialize. And in
> > most cases, you'd really need to reinitalize it; [...]
>
> If we want to
On Tue, Feb 24, 2015 at 10:44:05AM +0100, Ingo Molnar wrote:
> > This is the most common argument that's raised when live
> > patching is discussed. "Why do need live patching when we
> > have redundancy?"
>
> My argument is that if we start off with a latency of 10
> seconds and improve that
On 02/22/2015, 10:46 AM, Ingo Molnar wrote:
> Arbitrary live kernel upgrades could be achieved by
> starting with the 'simple method' I outlined in earlier
> mails, using some of the methods that kpatch and kGraft are
> both utilizing or planning to utilize:
>
> - implement user task and
On Tue 2015-02-24 11:23:29, Ingo Molnar wrote:
> What gradual improvements in live upgrade latency am I
> talking about?
>
> - For example the majority of pure user-space process
>pages in RAM could be saved from the old kernel over
>into the new kernel - i.e. they'd stay in place in
* Jiri Kosina wrote:
> [...] We could optimize the kernel the craziest way we
> can, but hardware takes its time to reinitialize. And in
> most cases, you'd really need to reinitalize it; [...]
If we want to reinitialize a device, most of the longer
initialization latencies during bootup
* Pavel Machek wrote:
> > More importantly, both kGraft and kpatch are pretty limited
> > in what kinds of updates they allow, and neither kGraft nor
> > kpatch has any clear path towards applying more complex
> > fixes to kernel images that I can see: kGraft can only
> > apply the simplest
* Josh Poimboeuf wrote:
> Your upgrade proposal is an *enormous* disruption to the
> system:
>
> - a latency of "well below 10" seconds is completely
> unacceptable to most users who want to patch the kernel
> of a production system _while_ it's in production.
I think this statement is
* Vojtech Pavlik wrote:
> On Sun, Feb 22, 2015 at 03:01:48PM -0800, Andrew Morton wrote:
>
> > On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina
> > wrote:
> >
> > > But if you ask the folks who are hungry for live bug
> > > patching, they wouldn't care.
> > >
> > > You mentioned "10
* Arjan van de Ven wrote:
> I think 10 seconds is Ingo being a bit exaggerating,
> since you can boot a full system in a lot less time than
> that, and more so if you know more about the system (e.g.
> don't need to spin down and then discover and spin up
> disks). If you're talking about
* Arjan van de Ven arjanvande...@gmail.com wrote:
I think 10 seconds is Ingo being a bit exaggerating,
since you can boot a full system in a lot less time than
that, and more so if you know more about the system (e.g.
don't need to spin down and then discover and spin up
disks). If
* Pavel Machek pa...@ucw.cz wrote:
More importantly, both kGraft and kpatch are pretty limited
in what kinds of updates they allow, and neither kGraft nor
kpatch has any clear path towards applying more complex
fixes to kernel images that I can see: kGraft can only
apply the
* Josh Poimboeuf jpoim...@redhat.com wrote:
Your upgrade proposal is an *enormous* disruption to the
system:
- a latency of well below 10 seconds is completely
unacceptable to most users who want to patch the kernel
of a production system _while_ it's in production.
I think this
* Vojtech Pavlik vojt...@suse.com wrote:
On Sun, Feb 22, 2015 at 03:01:48PM -0800, Andrew Morton wrote:
On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina jkos...@suse.cz
wrote:
But if you ask the folks who are hungry for live bug
patching, they wouldn't care.
You
* Jiri Kosina jkos...@suse.cz wrote:
[...] We could optimize the kernel the craziest way we
can, but hardware takes its time to reinitialize. And in
most cases, you'd really need to reinitalize it; [...]
If we want to reinitialize a device, most of the longer
initialization latencies
On 02/22/2015, 10:46 AM, Ingo Molnar wrote:
Arbitrary live kernel upgrades could be achieved by
starting with the 'simple method' I outlined in earlier
mails, using some of the methods that kpatch and kGraft are
both utilizing or planning to utilize:
- implement user task and kthread
On Tue, Feb 24, 2015 at 10:44:05AM +0100, Ingo Molnar wrote:
This is the most common argument that's raised when live
patching is discussed. Why do need live patching when we
have redundancy?
My argument is that if we start off with a latency of 10
seconds and improve that gradually,
On Tue, Feb 24, 2015 at 11:23:29AM +0100, Ingo Molnar wrote:
Your upgrade proposal is an *enormous* disruption to the
system:
- a latency of well below 10 seconds is completely
unacceptable to most users who want to patch the kernel
of a production system _while_ it's in
On Tue 2015-02-24 11:23:29, Ingo Molnar wrote:
What gradual improvements in live upgrade latency am I
talking about?
- For example the majority of pure user-space process
pages in RAM could be saved from the old kernel over
into the new kernel - i.e. they'd stay in place in RAM,
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
On Tue, Feb 24, 2015 at 11:53:28AM +0100, Ingo Molnar wrote:
* Jiri Kosina jkos...@suse.cz wrote:
[...] We could optimize the kernel the craziest way we
can, but hardware takes its time to reinitialize. And in
most cases, you'd really need to reinitalize it; [...]
If we want to
> kernel update as step one, maybe we want this on a kernel module
> level:
> Hot-swap of kernel modules, where a kernel module makes itself go
> quiet and serializes its state ("suspend" pretty much), then gets
> swapped out (hot) by its replacement,
> which then unserializes the state and
> More importantly, both kGraft and kpatch are pretty limited
> in what kinds of updates they allow, and neither kGraft nor
> kpatch has any clear path towards applying more complex
> fixes to kernel images that I can see: kGraft can only
> apply the simplest of fixes where both versions of a
On Mon, Feb 23, 2015 at 11:42:17AM +0100, Richard Weinberger wrote:
> > Of course, if you are random Joe User, you can do whatever you want, i.e.
> > also compile your own home-brew patches and apply them randomly and brick
> > your system that way. But that's in no way different to what you as
On Mon, Feb 23, 2015 at 9:17 AM, Jiri Kosina wrote:
> On Sun, 22 Feb 2015, Arjan van de Ven wrote:
> Of course, if you are random Joe User, you can do whatever you want, i.e.
> also compile your own home-brew patches and apply them randomly and brick
> your system that way. But that's in no way
On Sun, 22 Feb 2015, Arjan van de Ven wrote:
> There's a lot of logistical issues (can you patch a patched system... if
> live patching is a first class citizen you end up with dozens and dozens
> of live patches applied, some out of sequence etc etc).
I can't speak on behalf of others, but I
On Mon, Feb 23, 2015 at 11:42:17AM +0100, Richard Weinberger wrote:
Of course, if you are random Joe User, you can do whatever you want, i.e.
also compile your own home-brew patches and apply them randomly and brick
your system that way. But that's in no way different to what you as Joe
More importantly, both kGraft and kpatch are pretty limited
in what kinds of updates they allow, and neither kGraft nor
kpatch has any clear path towards applying more complex
fixes to kernel images that I can see: kGraft can only
apply the simplest of fixes where both versions of a
On Mon, Feb 23, 2015 at 9:17 AM, Jiri Kosina jkos...@suse.cz wrote:
On Sun, 22 Feb 2015, Arjan van de Ven wrote:
Of course, if you are random Joe User, you can do whatever you want, i.e.
also compile your own home-brew patches and apply them randomly and brick
your system that way. But that's
kernel update as step one, maybe we want this on a kernel module
level:
Hot-swap of kernel modules, where a kernel module makes itself go
quiet and serializes its state (suspend pretty much), then gets
swapped out (hot) by its replacement,
which then unserializes the state and continues.
On Sun, 22 Feb 2015, Arjan van de Ven wrote:
There's a lot of logistical issues (can you patch a patched system... if
live patching is a first class citizen you end up with dozens and dozens
of live patches applied, some out of sequence etc etc).
I can't speak on behalf of others, but I
On Sun, Feb 22, 2015 at 03:01:48PM -0800, Andrew Morton wrote:
> On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina wrote:
>
> > But if you ask the folks who are hungry for live bug patching, they
> > wouldn't care.
> >
> > You mentioned "10 seconds", that's more or less equal to infinity
There's failover, there's running the core services in VMs (which can
migrate)...
I think 10 seconds is Ingo being a bit exaggerating, since you can
boot a full system in a lot less time than that, and more so if you
know more about the system
(e.g. don't need to spin down and then discover and
On 23 February 2015 at 09:01, Andrew Morton wrote:
> On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina wrote:
>
>> But if you ask the folks who are hungry for live bug patching, they
>> wouldn't care.
>>
>> You mentioned "10 seconds", that's more or less equal to infinity to them.
>
> 10
On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina wrote:
> But if you ask the folks who are hungry for live bug patching, they
> wouldn't care.
>
> You mentioned "10 seconds", that's more or less equal to infinity to them.
10 seconds outage is unacceptable, but we're running our service
[ added live-patching@ ML as well, in consistency with Josh ]
On Sun, 22 Feb 2015, Ingo Molnar wrote:
> It's all still tons of work to pull off a 'live kernel upgrade' on
> native hardware, but IMHO it's tons of very useful work that helps a
> dozen non-competing projects, literally.
Yes, I
On Sun, 22 Feb 2015, Josh Poimboeuf wrote:
> Yes, there have been some suggestions that we should support multiple
> consistency models, but I haven't heard any good reasons that would
> justify the added complexity.
I tend to agree, consistency models were just a temporary idea that seems
to
On Sun, Feb 22, 2015 at 08:37:58AM -0600, Josh Poimboeuf wrote:
> On Sun, Feb 22, 2015 at 10:46:39AM +0100, Ingo Molnar wrote:
> > - the whole 'consistency model' talk both projects employ
> >reminds me of how we grew 'security modules': where
> >people running various mediocre projects
[ adding live-patching mailing list to CC ]
On Sun, Feb 22, 2015 at 10:46:39AM +0100, Ingo Molnar wrote:
> * Ingo Molnar wrote:
> > Anyway, let me try to reboot this discussion back to
> > technological details by summing up my arguments in
> > another mail.
>
> So here's how I see the kGraft
* Ingo Molnar wrote:
> We have many of the building blocks in place and have
> them available:
>
> - the freezer code already attempts at parking/unparking
> threads transparently, that could be fixed/extended.
>
> - hibernation, regular suspend/resume and in general
> power
* Ingo Molnar wrote:
> - implement live kernel upgrades by:
>
> - snapshotting all system state transparently
Note that this step can be sped up further in the end,
because most of this work can be performed asynchronously
and transparently prior to the live kernel upgrade step
* Ingo Molnar mi...@kernel.org wrote:
- implement live kernel upgrades by:
- snapshotting all system state transparently
Note that this step can be sped up further in the end,
because most of this work can be performed asynchronously
and transparently prior to the live kernel
* Ingo Molnar mi...@kernel.org wrote:
We have many of the building blocks in place and have
them available:
- the freezer code already attempts at parking/unparking
threads transparently, that could be fixed/extended.
- hibernation, regular suspend/resume and in general
[ adding live-patching mailing list to CC ]
On Sun, Feb 22, 2015 at 10:46:39AM +0100, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
Anyway, let me try to reboot this discussion back to
technological details by summing up my arguments in
another mail.
So here's how I see the
[ added live-patching@ ML as well, in consistency with Josh ]
On Sun, 22 Feb 2015, Ingo Molnar wrote:
It's all still tons of work to pull off a 'live kernel upgrade' on
native hardware, but IMHO it's tons of very useful work that helps a
dozen non-competing projects, literally.
Yes, I
On Sun, Feb 22, 2015 at 08:37:58AM -0600, Josh Poimboeuf wrote:
On Sun, Feb 22, 2015 at 10:46:39AM +0100, Ingo Molnar wrote:
- the whole 'consistency model' talk both projects employ
reminds me of how we grew 'security modules': where
people running various mediocre projects would
On Sun, 22 Feb 2015, Josh Poimboeuf wrote:
Yes, there have been some suggestions that we should support multiple
consistency models, but I haven't heard any good reasons that would
justify the added complexity.
I tend to agree, consistency models were just a temporary idea that seems
to
On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina jkos...@suse.cz wrote:
But if you ask the folks who are hungry for live bug patching, they
wouldn't care.
You mentioned 10 seconds, that's more or less equal to infinity to them.
10 seconds outage is unacceptable, but we're running our
On Sun, Feb 22, 2015 at 03:01:48PM -0800, Andrew Morton wrote:
On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina jkos...@suse.cz wrote:
But if you ask the folks who are hungry for live bug patching, they
wouldn't care.
You mentioned 10 seconds, that's more or less equal to
On 23 February 2015 at 09:01, Andrew Morton a...@linux-foundation.org wrote:
On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina jkos...@suse.cz wrote:
But if you ask the folks who are hungry for live bug patching, they
wouldn't care.
You mentioned 10 seconds, that's more or less equal to
There's failover, there's running the core services in VMs (which can
migrate)...
I think 10 seconds is Ingo being a bit exaggerating, since you can
boot a full system in a lot less time than that, and more so if you
know more about the system
(e.g. don't need to spin down and then discover and
54 matches
Mail list logo
