Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
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).
> 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.