Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Ingo Molnar <mingo@elte.hu>]

* Andi Kleen <ak@suse.de> wrote:

> Ingo Molnar <mingo@elte.hu> 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