[LITMUS^RT] litmus-dev Digest, Vol 60, Issue 10

Thu Feb 23 06:31:47 CET 2017

PS: The timestamp LOCK_SUSPEND is used to measure the prue overheads of
pfp-scheduler (the code between the run queue locks). The scheduler name is
MRSP but it is hard coded... it is actually pfp-scheduler running. Sorry
for this.

On 23 February 2017 at 02:17, Shuai Zhao <zs673 at york.ac.uk> wrote:

> Hi Björn
>
> Sorry for the picture.
>
> Here I attached the testing results for the original pfp-scheduler. We use
> a Quad-Core AMD 8350 Processor 2GHz with a three level cache architecture
> (512kb, 2048kb, 2mb).
>
> We have not done anything to prevent the cache interference... However,
> even if so, it should give a relatively stable max value for each identical
> test with a sufficient number of samples (i.e. executing the longest code
> path in pfp-scheduler), am I correct?
>
> I am running a "meaningless" test with a increasing number of processor,
> from 1 to 16, and expect a relatively stable max overheads for each test
> (just to have a view of how the system can interfer the scheduler
> execution). On each processor there are 5 tasks that keep releasing and
> executing.
>
> Thank you for your help.
>
> Best wishes
> Shuai
>
>
>
>
>
> On 22 February 2017 at 11:00, <litmus-dev-request at lists.litmus-rt.org>
> wrote:
>
>> Send litmus-dev mailing list submissions to
>>         litmus-dev at lists.litmus-rt.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.litmus-rt.org/listinfo/litmus-dev
>> or, via email, send a message with subject or body 'help' to
>>         litmus-dev-request at lists.litmus-rt.org
>>
>> You can reach the person managing the list at
>>         litmus-dev-owner at lists.litmus-rt.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of litmus-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: litmus-dev Digest, Vol 60, Issue 4 (Björn Brandenburg)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 21 Feb 2017 16:55:09 +0100
>> From: Björn Brandenburg <bbb at mpi-sws.org>
>> To: litmus-dev at lists.litmus-rt.org
>> Subject: Re: [LITMUS^RT] litmus-dev Digest, Vol 60, Issue 4
>> Message-ID: <DEF99AB7-E5D5-4D18-8ABB-8E22E9115A57 at mpi-sws.org>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>> > On 21 Feb 2017, at 15:20, Shuai Zhao <zs673 at york.ac.uk> wrote:
>> >
>> > The code I posted in the email is protected by a spin lock to avoid
>> race conditions. The tickets are maintained and obtained by atomic_t
>> variables.
>>
>> Ok, then the code is somewhat misleading. A regular unsigned long would
>> do.
>>
>> >
>> > Using the feather-trace tool we get a csv file, where all the overheads
>> are recorded. I noticed that you processed the data as max, 99.9prec,
>> 99prec and 95prec. I wonder what is the rational behind this?
>>
>> These are cutoffs that have been frequently used in prior work, so it’s
>> interesting to see what the data looks like at these commonly used points.
>>
>> >
>> > Is that the 99,9prec or 99prec result filter out some of the out-layer
>> data which is influenced by the system overheads or interrupts?
>>
>> Well, they cut off a part of the distribution. Whether you may reasonably
>> consider these parts to be “outliers” depends on your hardware,
>> experimental setup, and goal of the experiments. It’s a judgement call.
>>
>> >
>> > For example: we tried to gather the overheads of the original
>> pfp-scheduler. we did this experiment with a increasing number of
>> processors and expect a constant overheads. However, the data we have is
>> confusing. The samples for each test is above one million.
>> >
>> > <Screen Shot 2017-02-21 at 13.23.45.png>
>>
>> Could you please provide numeric data as inline text or as a CSV file? A
>> picture is not so helpful here…
>>
>> >
>> > We gather this data inside the pfp-scheduler (we put time stamps inside
>> the run queue locks) to get the exact overheads for executing the
>> scheduling code. The result above gives the max overhead we observed in
>> each test.
>> >
>> > As shown in the result, the overheads of the pfp-scheduler is extremely
>> high when using cpu 1,2 and 4. By repeating the same tests, we can often
>> observe such a extreme value, but with different number of cpus.
>>
>> I don’t understand your question. You are *measuring* a long-tail
>> distribution. Of course you are going to see rare values stemming from the
>> long tail only, well, rarely.
>>
>> If you see heavily fluctuating “observed max” values from run to run,
>> then you are likely not using enough samples.
>>
>> >
>> > A more simple example: the lock function that I post on previous email
>> with the kmalloc removed. This part of code has only one path and is O(1),
>> shich suppose to have a stable overhead.
>> > <Screen Shot 2017-02-21 at 13.31.46.png>
>> > However, as shown above, the overheads of the code is extremely high
>> with 2,14 and 15 cpus.
>> >
>> > I wonder have you met any sitations like this before? and how you
>> explain such a result or how you solve the problem(if there is).
>> >
>> > Do you have any suggestions when facing such a confusing result?
>>
>> What hardware platform are you using?
>>
>> Are you doing anything to prevent cross-core cache interference?
>>
>> - Björn
>>
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> litmus-dev mailing list
>> litmus-dev at lists.litmus-rt.org
>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>
>>
>> ------------------------------
>>
>> End of litmus-dev Digest, Vol 60, Issue 10
>> ******************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170223/9fa1fd1e/attachment-0001.html>