Re: [RFC] [rt-tests] change to cyclictest behavior

[Carsten Emde <Carsten.Emde@osadl.org>]

On 01/06/2010 08:39 PM, John Kacur wrote:
> On Wed, Jan 6, 2010 at 8:04 PM, Clark Williams <williams@redhat.com> wrote:
>> I have a problem with the way cyclictest sets up measurement threads,
>> but before I went and changed things I thought I would ask if people
>> cherished this particular behavior.
>>
>> Currently, when cyclictest is run with multiple threads (i.e. -t
>> option) it distributes both the sample interval and the realtime
>> priority by adding the 'distance' parameter to the interval and
>> decrementing the priority by one. This means if you have a distance of
>> 500us (default), a specified RT priority of 95 and start four threads,
>> they will be started with the following parameters:
>>
>> $ cyclictest -t4 -p95
>>
>> Will give you:
>>
>> thread          priority        sample interval
>> 0               95              500
>> 1               94              1000
>> 2               93              1500
>> 3               92              2000
>>
>> What I'd like to do is modify this logic so that when '-a' (affinity) is
>> specified, the priority and sample interval will not be altered. I
>> don't think there's any point in distributing the priority's and
>> sample intervals when the measurement threads are pinned to their own
>> CPU.
>>
>> So:
>>
>> $ cyclictest -t4 -p95 -a
>>
>> Would have each thread at SCHED_FIFO 95 and a sample interval of 500us.
>>
>> Note that this behavior also occurs when the histogram (-h) option is
>> specified).
> Seems reasonable to me. Maybe it would also be nice to have a flag to
> get the old behaviour back even with -a?
I know that there are quite a few people out there who get furious, if
someone breaks backward compatibility - especially in things that are
used for automatic testing. Cyclictest is such a thing.

In addition, I would propose to consider not only affinity but also the
number of threads. If, for example, someone specifies -a -t5 on a
four-way machine, then it may not make sense to use the same priority
and the same interval on all threads. If any, the new feature would only
make sense in cases where both the -a and the -t option do not have an
argument so the number of threads matches the number of CPUs and every
thread runs on its own CPU. Another pitfall is hyperthreading in which
case it may be desired to have as many threads at the same priority as
real CPUs rather than as available hyperthreads.

Here is my proposal:
Do not change the meaning of existing options. Introduce a new option
that is mutual exclusive with the -a, the -t and the -d option. This new
option does the same as -a and -t and -d0 and sets the same priority to
all threads. How about that?

	Carsten.