* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Quoting Chris Wright ([EMAIL PROTECTED]):
> > > A little surprising: kernbench is improved, but dbench and tbench
> > > are worse - though within the 95% CI.
> >
> > It is interesting. Would be good to see what happens with the cap_ bits
> > used i
Quoting Chris Wright ([EMAIL PROTECTED]):
> > A little surprising: kernbench is improved, but dbench and tbench
> > are worse - though within the 95% CI.
>
> It is interesting. Would be good to see what happens with the cap_ bits
> used in SELinux instead of secondary callout.
Here are the new n
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Here are some numbers on a 4way x86 - PIII 700Mhz with 1G memory (hmm,
> highmem not enabled). I should hopefully have a 2way ppc available
> later today for a pair of runs.
Thanks for running these numbers Serge.
> dbench and tbench were run 50 t
Quoting Stephen Smalley ([EMAIL PROTECTED]):
> On Fri, 2005-08-26 at 04:23 -0500, [EMAIL PROTECTED] wrote:
> > Here are some numbers on a 4way x86 - PIII 700Mhz with 1G memory (hmm,
> > highmem not enabled). I should hopefully have a 2way ppc available
> > later today for a pair of runs.
> >
> >
On Fri, 2005-08-26 at 04:23 -0500, [EMAIL PROTECTED] wrote:
> Here are some numbers on a 4way x86 - PIII 700Mhz with 1G memory (hmm,
> highmem not enabled). I should hopefully have a 2way ppc available
> later today for a pair of runs.
>
> dbench and tbench were run 50 times each, kernbench and r
Quoting Chris Wright ([EMAIL PROTECTED]):
> * Chris Wright ([EMAIL PROTECTED]) wrote:
> > I'll have some numbers tomorrow. If you'd like to run SELinux that'd
> > be quite useful.
>
> These are just lmbench and kernel build numbers (certainly not the best
> for real benchmark numbers, but easy to
* Chris Wright ([EMAIL PROTECTED]) wrote:
> I'll have some numbers tomorrow. If you'd like to run SELinux that'd
> be quite useful.
These are just lmbench and kernel build numbers (certainly not the best
for real benchmark numbers, but easy to get a quick view run). This is
just baseline (i.e. d
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Did you ever check this with selinux?
No, thanks for catching that oversight.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majo
Did you ever check this with selinux? I'm assuming that the problem is
that selinux does things like:
rc = secondary_ops->task_create();
when secondary_ops->task_create can now be null...
(Will whip up the obvious patch asap - later this morning)
-serge
Quoting [EMAIL PROTECTED] ([EMAIL
Hmm, haven't yet figured out why, but something in this patchset
doesn't work for power5. Oops attached, as well as the assembly
for selinux_task_create (which I'm weeding through right now).
thanks,
-serge
Oops output from console:
Security Framework v1.0.0 initialized
SELinux: Initializing.
* James Morris ([EMAIL PROTECTED]) wrote:
> On Wed, 24 Aug 2005, Chris Wright wrote:
>
> > This is based on Kurt's original work. The net effect is that
> > LSM hooks are called conditionally, and in all cases capabilities
> > provide the defaults. I've done some basic performance testing, and
>
On Wed, 24 Aug 2005, Chris Wright wrote:
> This is based on Kurt's original work. The net effect is that
> LSM hooks are called conditionally, and in all cases capabilities
> provide the defaults. I've done some basic performance testing, and
> found nothing surprising.
Do you mean nothing noti
This is based on Kurt's original work. The net effect is that
LSM hooks are called conditionally, and in all cases capabilities
provide the defaults. I've done some basic performance testing, and
found nothing surprising. I'm interested to see numbers from others
before I push this up. These ar
13 matches
Mail list logo
