Ingo Molnar wrote:
i think we should actually do #1 unconditionally.
ISTs are bad for the native kernel too. They have various nasty
complications in the stack walker (and hence they _reduce_ reliability in
practice), and they are non-preemptible as well. Plus we have the
maximum-stack-footprint ftrace plugin now, which can remove any perception
about how bad the worst-case stack footprint is in practice.
If it ever becomes an issue we could also soft-switch to a larger (per
CPU) exception stack from the exception handlers themselves. The
architectural stack footprint of the various critical exceptions are
calculatable and low - so we could switch away and get almost the kind of
separation that ISTs give. There's no deep reason to actually make use of
hw switched ISTs.
So feel free to send a patch that just standardizes the critical
exceptions to use the regular kernel stack. (I havent actually tried this
but it should be relatively simple to implement. Roadblocks are possible.)
Certainly. There is provision for a debug stack that can be larger than
the normal exception stack. This is used for vectors 1 and 3. If we
wish to preserve this, we need to to manual stack switching.
Currently DEBUG_STKSZ is 8K, the same as the normal stack (compared to
4K for the other execption stacks). Do we need to implement stack
switching for debug vectors?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
