On Mon, Apr 07, 2008, maximilian attems wrote: > On Mon, Apr 07, 2008 at 12:47:56AM +0200, Sam Hocevar wrote: > > > > CONFIG_SECCOMP was disabled for performance reasons, but it has always > > been harmless. Quoting the author: > > > > | On x86-64 SECCOMP generates absoutely zero performance hit. > > | > > | The original seccomp patch for x86 also generated absolutely zero > > | performance hit, both pratically and theoretically too. _zero_ CPU > > | cycles of difference, zero cachelines. > > > > (From http://marc.info/?l=linux-kernel&m=115235061904105) > > that's pretty wrong. > it had a hit on each context switch.
Okay, but I'm not asking for CONFIG_SECCOMP_DISABLE_TSC, just CONFIG_SECCOMP, which is completely harmless (unless you can tell me where the harm is). > > Please re-enable this feature. It is needed for CPUShare (see #417130). > > no. > that is a commercial entity, no need to push that. CPUShare is not a commercial entity, it is a piece of software I use and package and is unfortunately non-functional on Debian systems because CONFIG_SECCOMP is disabled. I see no reason for deliberately diverging from the upstream kernel for political reasons that have nothing to do with our social contract (and probably violate 4.). > unless something substantial comes up that bug can be close right away. Wow, thanks for listening to the users. Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
