> Does anyone have a theory why syscalls are so expensive in FreeBSD? Here
> are the results of unixbench 4.1 on two machines. First is the machine
> running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386
> mode), 2 GHz:
I ran the syscall benchmark from UnixBench on the same hard
Bruce Evans wrote:
> FreeBSD has more layers, with less optimization in each layer. Normally
> this doesn't matter, since everyone knows that syscalls are expensive
> and avoids them :-).
My point is that the majority of applications are written for Linux and
they are both syscall-intensive and
Kris Kennaway wrote:
> So it is using getpid? It should be fine on FreeBSD with the previous
> provisos, but you also need to check Linux behaviour and compare on
> identical hardware before you can draw conclusions.
Here's the source of unixbench syscall benchmark:
unsigned long iter;
void re
On Tue, 1 Jan 2008, Jeff Roberson wrote:
On Tue, 1 Jan 2008, Gergely CZUCZY wrote:
There's this SYSCALL CPU extension with the SYSENTER/SYSEXIT features. IIRC
Linux takes advantage of this, while FreeBSD doesn't. I might be wrong
here,
of course.
This is true on 32bit x86 and not true on
Ivan Voras wrote:
Kris Kennaway wrote:
That's why it's important to dig into the details of what the benchmark
is actually doing before you conclude that "the numbers are higher for
linux, therefore it has faster syscalls".
Can you propose a simpler syscall on the GENERIC kernel that could be
Kris Kennaway wrote:
> It is likely to remain in people's custom kernels, possibly including
> the one used by Ivan. Anyway, this is all speculation until someone
> studies the claims in more detail.
I'm using GENERIC minus debugging options.
signature.asc
Description: OpenPGP digital signatu
Kris Kennaway wrote:
> That's why it's important to dig into the details of what the benchmark
> is actually doing before you conclude that "the numbers are higher for
> linux, therefore it has faster syscalls".
Can you propose a simpler syscall on the GENERIC kernel that could be
used instead of
Roman Divacky wrote:
BTW, now with COMPAT_43 gone out of GENERIC, is it necesary to keep
COMPAT_43TTY, even when Linux emulation is not needed?
COMPAT_43TTY just adds a bunch of sysctls, it does not slow down anything.
COMPAT_43 did slow down things (the getpid for example) and it was remove
>BTW, now with COMPAT_43 gone out of GENERIC, is it necesary to keep
> COMPAT_43TTY, even when Linux emulation is not needed?
COMPAT_43TTY just adds a bunch of sysctls, it does not slow down anything.
COMPAT_43 did slow down things (the getpid for example) and it was removed.
I dont see any pr
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 03:19:29PM +0100, Kris Kennaway wrote:
Vlad GALU wrote:
On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUC
On Tue, Jan 01, 2008 at 03:19:29PM +0100, Kris Kennaway wrote:
> Vlad GALU wrote:
> >On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> >>Gergely CZUCZY wrote:
> >>>On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
> Ivan Voras wrote:
> >Kris Kennaway wrote:
> >>Gergely
Vlad GALU wrote:
On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same f
On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Gergely CZUCZY wrote:
> > On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
> >> Ivan Voras wrote:
> >>> Kris Kennaway wrote:
> Gergely CZUCZY wrote:
> >> It looks like myisam is doing huge numbers of concurrent reads of th
Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same file which is running into exclusive locking in the kernel
(vnode interl
On Tue, 1 Jan 2008, Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same file which is running into exclusive locking in the
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
> Ivan Voras wrote:
> >Kris Kennaway wrote:
> >>Gergely CZUCZY wrote:
> It looks like myisam is doing huge numbers of concurrent reads of the
> same file which is running into exclusive locking in the kernel
> (vnode interlo
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same file which is running into exclusive locking in the kernel
(vnode interlock and lockbuilder mtxpool). Does it not do any
caching of the data in userspace bu
17 matches
Mail list logo
