public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@cpushare.com>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: disable tsc with seccomp
Date: Sat, 5 Nov 2005 17:31:35 +0100	[thread overview]
Message-ID: <20051105163134.GC14064@opteron.random> (raw)
In-Reply-To: <200511051712.09280.ak@suse.de>

On Sat, Nov 05, 2005 at 05:12:09PM +0100, Andi Kleen wrote:
> It is normally on on all x86-64 systems.

Can the performance counters be disabled for seccomp only right?

> I definitely don't want any code like this in the context switch. It is 
> critical and I don't want to pollute fast paths with stuff like this
> that nobody needs.

287 registered CPUShare users will appreciate to compute more securely
thanks to this feature (about 10 up at any given time), and once I start
allowing transactions I hope much more users will need this (it's not
finished yet). 

We have in the kernel lots of features that slowdown a bit and that
benefit only a part of the userbase. Even kmap only benefits people with
>1G of ram. Even the security_* api in the syscalls only benefit a part
of the userbase. There are infinite other examples. The point is that
none of this is measurable, _especially_ this one in the context switch,
context switches aren't as frequent as syscalls! It's only two
cachelines at every context switch, and they might be hot already since
we're mangling over the task struct of the prev/next regardless of my
patch. If something we could discuss how to pack the seccomp structure
in the task structure so that it's already hot. But calling my feature
"pollution" seems a bit exaggerated to me.

Plus Andrew would have never allowed it to go in, if this could have
impacted performance, you also should know this can't slowdown anything
and you're just talking about theory.

Of course if 1000 other people also adds their feature to the context
switch then it might become measurable, but this is the first time we
had to change the context switch to add more security on per-task basis,
so I don't see it happening any time soon. Plus if it happens we can
implement some technique to share the same cacheline for multiple
purposes so it remains a fixed cost (like an hook). If you tell me how
to use an hook today that avoids me to touch two cachelines in the
context switch fast path, let me know, I don't see it.

  reply	other threads:[~2005-11-05 16:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-05 13:47 disable tsc with seccomp Andrea Arcangeli
2005-11-05 15:37 ` Andi Kleen
2005-11-05 16:07   ` Andrea Arcangeli
2005-11-05 16:12     ` Andi Kleen
2005-11-05 16:31       ` Andrea Arcangeli [this message]
2005-11-05 17:04         ` Andi Kleen
2005-11-06  1:55           ` Andrea Arcangeli
2005-11-21 16:43             ` Andrea Arcangeli
2005-11-21 17:05               ` Andi Kleen
2005-11-21 17:16                 ` Andrea Arcangeli
2005-11-21 17:24                   ` Andi Kleen
2005-11-21 17:38                     ` Andrea Arcangeli
2005-11-21 18:40                       ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051105163134.GC14064@opteron.random \
    --to=andrea@cpushare.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox