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

[Shuai Zhao]

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/09e97d55/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test result.zip
Type: application/zip
Size: 9126 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170223/09e97d55/attachment.zip>