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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
