lkml.org 
[lkml]   [2008]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kvm vmload/vmsave vs tss.ist
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



\
 
 \ /
  Last update: 2008-12-25 16:49    [W:1.025 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site