lkml.org 
[lkml]   [2005]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Fastboot] Re: [PATCH] ppc64: kexec support for ppc64
Hello Andrew,

On Fri, May 06, 2005 at 04:05:46PM -0700, Andrew Morton wrote:
>
> This kdump/kexec stuff has been hanging around for far too long, IMO. I'd
> like to think about what we can do to get things moving along a bit more.
>
> I have two issues with it:
>
> a) Vague feelings that the low-level ia32 changes may cause APIC/etc
> breakage with some PCs.
>
> b) Much more significantly: I still do not believe that it has been
> demonstrated that the whole kdump-via-kexec scheme will have a
> sufficiently high success rate for this to become Linux's way of doing
> crashdumps.

This is a chicken-and-egg problem. Unless we have kexec/kdump
in mainline with a lot of users, we may not find out all the
corner cases.

> And it would not be good if in six months time we decide that the
> practical problems in getting it all working sufficiently well are
> insurmountable and we have to revert it all and start working on
> something else.
>
> So am I right to have this concern? If so, how can we settle this?
> (ie: who's going to do it? ;))
>
>
> Perhaps we could declare that kexec is sufficiently useful and mature in
> its own right and just merge up those bits while we work on kdump. This
> also gives us a bit of pipelining: continue to test and stabilise kexec
> while kdump remains in development.
>
> Opinions are sought...

FWIW, based on prior experience in other OS, I believe that kexec
based approach is the most flexible and safest for supporting such
a diverse set of platforms that linux supports. The issues however
are -

1. I don't think we can achieve kdump with very high reliability within
the few months it has had so far. Again, if prior experience
with similar mechanism is worth anything, it will take a long
time to achieve very high reliability on dozens of chipsets, several
cpus, dozens of different platforms and various combinations
thereof not to mention many different situations when kdump
is used.

2. The way I see it, beyond a certain amount reliability (common
x86, x86_64, ppc64 platforms, normal kernel developer use), we
will need exposure to a much larger user base (large customer
deployments will be the most useful) to find and sort out the remaining
corner cases.

I hope we have it available for a large user base in mainline
as soon as it is reliable enough for common platforms and
kernel developer use.

Thanks
Dipankar
-
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-05-07 10:53    [W:0.071 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site