On Thu, Apr 10, 2008 at 04:53:16AM +0200, Andrea Arcangeli wrote: > Hello, > > The story about seccomp is that as long as there are users CPUShare > will support it because it's a more efficient and more secure > computing model. > > About the seccomp overhead, that is zero. It adds zero overhead to the > fast path of the scheduler. It never added any overhead on x86-64. For > x86 I added a tsc_disable feature that wasn't zero overhead initially > and so that was used as argument against seccomp (despite it really > had little to do with the seccomp core), it is zero overhead now that > I optimized that little tsc_disable feature. > > So you can always enable seccomp on x86-64 without performance > worries (I guess it only adds an hundred byte of .text). > > On x86 you can enable seccomp as safely as on x86-64 if you find a > TIF_NOTSC implemented in your x86 32bit kernel. TIF_NOTSC is zerocost > and so after implementing TIF_NOTSC, I changed seccomp to use it to > avoid any overhead in all archs. > > In the latest kernels the only overhead generated by seccomp is a bit > larger .text image, everything else is false or obsolete.
What about non-x86 architectures, well i guess ia64 and powerpc/powerpc64 are the most interesting candidates. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
