Re: [PATCH 7/15] misc: Make x86 doublefault handling optional
From: Ingo Molnar
Date: Tue Dec 13 2005 - 03:40:06 EST
* Andi Kleen <ak@xxxxxxx> wrote:
> Ingo Molnar <mingo@xxxxxxx> writes:
> >
> > in the past couple of years i saw double-faults at a rate of perhaps
> > once a year - and i frequently hack lowlevel glue code! So the
> > usefulness of this code in the field, and especially on an embedded
> > platforms, is extremely limited.
>
> If it only saves an hour or developer time on some bug report it has
> already justified its value.
yes, of course. Are you arguing that all debugging options should be
made unconditional? Matt's patch simply makes double-fault-debugging
optional. More than that, it will still be unconditionally enabled
unless CONFIG_EMBEDDED is specified.
> Also to really save memory there are much better areas of attack than
> this relatively slim code.
the dynamics of memory reduction patches is just like the dynamics of
scalability patches: we have to attack on _every front_ and even then
progress will appear to be very slow. We almost never reject a
scalability micro-optimization just because there might be larger fruits
hanging.
> > in fact, i've experienced triple-faults (== spontaneous reboots) to
> > be at least 10 times more frequent than double-faults! I.e. _if_
> > your kernel (or hardware) is screwed up to the degree that it would
> > double-fault, it will much more likely also triple-fault.
>
> A common case where this doesn't hold is breaking the [er]sp in kernel
> code.
>
> -Andi (who sees double faults more often)
yeah. Still, i see no problem with making it optional. (as long as it
does not result in significant uglification of the code - which clearly
is not a problem for this particular patch.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/