Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Sep 2002 11:18:29 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Bill Huey (Hui)" <billh@gnuppy.monkey.org>
Cc:        Daniel Eischen <eischen@pcnet1.pcnet.com>, freebsd-arch@FreeBSD.ORG
Subject:   Re: New Linux threading model
Message-ID:  <3D8B6675.C116587F@mindspring.com>
References:  <20020920031423.GA3380@gnuppy.monkey.org> <Pine.GSO.4.10.10209200002280.2162-100000@pcnet1.pcnet.com> <20020920082828.GA4207@gnuppy.monkey.org>

next in thread | previous in thread | raw e-mail | index | archive | help
"Bill Huey (Hui)" wrote:
> They did some measurements, but I'm curious
> how something like thread performance (context switching, blocking)
> in libc_r measures against their 1:1 model. It should be simple
> to write a test program to check it out and see what kind of
> result they get.

The correct approach is to run a number of instances of the program
equal to the number of CPU's + 1, simultaneously, and take the total
run time.

The issue here is going to be that, on a quiesecent system, you
do not have contention for the CPU except threads in the same
process, if you run only one threaded test program.

The result of running only one test program will therefore not
show the effects of TLB shootdown that come from the threads all
existing in the same scheduling contention domain with other
processes on the system.

This would lead to really good microbenchmark results, but really
poor real-world performance.

The need for "number of CPU's + 1" instances is to prevent the
same masking of the effect of negaffinity, and the masking of the
effect of contention on a naieve affinity algorithm.

In theory, a 1:1 implementation should degrade exponentially in
contention, and this effect will be further increased by inter-CPU
scheduling.

The net weefect of the test I have suggested should be most evident
by comparing the number of inter-CPU and intra-CPU migrations which
take place (assuming they have statistics counters for this).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D8B6675.C116587F>