Package: linux-image-2.6.24-1-amd64
Version: 2.6.24-5
Severity: important

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)

Please re-enable this feature. It is needed for CPUShare (see #417130).

-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24.3 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.

> Please re-enable this feature. It is needed for CPUShare (see #417130).

no.
that is a commercial entity, no need to push that.

unless something substantial comes up that bug can be close right away.

--
maks



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Apr 07, 2008 at 07:51:41AM +0000, maximilian attems wrote:
> that is a commercial entity, no need to push that.
>
> unless something substantial comes up that bug can be close right away.

It seems that you're not really forced to use the commercial side. CPUShare
may be use freely if you want to give CPU time for some free projects which
need it.

Is there some real-word benchmark about SECCOMP impact on performances?

Cheers,
--
Yves-Alexis



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Apr 07, 2008 at 11:21:24AM +0200, Sam Hocevar wrote:
> 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).

it adds useless bloat.

the SECCOMP_DISABLE_TSC is crazy, that is adding a couple of
instructions to the hottest scheduler path.

> > > 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.

why would we diverge from upstream?
what's that nonesense.
each distribution is free to choose and adapt it's .config.

> 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.

if it had users we already would have been notified.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Apr 07, 2008, maximilian attems wrote:
> On Mon, Apr 07, 2008 at 11:21:24AM +0200, Sam Hocevar wrote:
> > 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).
>
> it adds useless bloat.

It is not useless, I maintain a package that needs it.

> the SECCOMP_DISABLE_TSC is crazy, that is adding a couple of
> instructions to the hottest scheduler path.

Again, I am not asking for SECCOMP_DISABLE_TSC.

> why would we diverge from upstream?
> what's that nonesense.
> each distribution is free to choose and adapt it's .config.

I am not complaining about diverging from upstream, which is a
perfectly natural thing to do. I am complaining about diverging from
upstream for your own political agenda that you have no right to enforce
using your Debian hat if it violates our social contract.

> if it had users we already would have been notified.

Oh please. It's really depressing to spend so much time creating a
proper package, and seeing that the people who have the power to help
make it work do not wish to do so for obscure reasons. If you have a
personal grudge against seccomp, maybe you can let someone else in the
team activate it?

Regards,
--
Sam.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

block 477674 by 474648
thanks

On Mon, Apr 07, 2008, maximilian attems wrote:
> > > unless something substantial comes up that bug can be close right away.
> >
> > Wow, thanks for listening to the users.
>
> if it had users we already would have been notified.

By the way, our first research paper using results computed using
CPUShare will be presented at the International Conference on Image and
Signal Processing 2008 (and published by Springer-Verlag in the ICISP
proceedings as LNCS 5099-0038). We could not credit Debian.

Cheers,
--
Sam



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

tags 474648 +patch
thanks

On Mon, Apr 07, 2008, Sam Hocevar wrote:
> Package: linux-image-2.6.24-1-amd64
> Version: 2.6.24-5
> Severity: important
>
> CONFIG_SECCOMP was disabled for performance reasons, but it has always
> been harmless.

Dear maintainers,

any news on this issue? I see that you have uploaded 8 new kernel
packages since my original report, but each time you inadvertently
forgot to fix the bug :-(

I am attaching a patch in order to help you in the task. It only
reactivates CONFIG_SECCOMP for the architectures used by cpushare in
order to reduce the induced bloat which I know you despise.

Yes, I am perfectly aware that the fix adds a massive 274-byte
overhead to most kernels. I agree this is not acceptable. But this
time I thought of everything before I abused your precious time for my
selfish deeds! Attached is an additional patch that crops the boot-time
logo to 72x80 instead of 80x80 in order to spare up to *640 bytes* per
kernel image!! I noticed that penguins were mostly vertical animals,
so the logo has all these extra black pixels on the sides that can be
removed in order to create smaller, more efficient kernels. I believe
this kind of optimisation could benefit all Debian users.

Let me know if I can be of further assistance, for instance by
preparing an NMU for you.

Best regards,
--
Sam.