[LITMUS^RT] PFAIR policy issue update
Mihai-Iulian Gheorghe
gheorghe at student.chalmers.se
Fri Oct 4 17:34:19 CEST 2013
Hello,
Since the "rtspin" utility was not being executed at all, I reinstalled the "liblitmus" library. When I executed "rtspin 50 100 60", the CPU utilization was at 98%.
My system is composed of Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz and it is worth to be taken into account the fact, that only one core was busy at 98%, the other one was idle.
I am not sure what caused "rtspin" not to function properly in the first installation.
Best regards,
Mihai Gheorghe
-----Original Message-----
From: litmus-dev-bounces at lists.litmus-rt.org [mailto:litmus-dev-bounces at lists.litmus-rt.org] On Behalf Of litmus-dev-request at lists.litmus-rt.org
Sent: Friday, October 04, 2013 12:00 PM
To: litmus-dev at lists.litmus-rt.org
Subject: litmus-dev Digest, Vol 22, Issue 4
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: liblitmus: prop/cpp-safe (Bj?rn Brandenburg)
2. Re: PFair policy issue (Bj?rn Brandenburg)
3. Re: Compilation problem with liblitmus (Bj?rn Brandenburg)
4. Re: IPI vs. Cache Affinity (Bj?rn Brandenburg)
----------------------------------------------------------------------
Message: 1
Date: Fri, 4 Oct 2013 09:52:11 +0200
From: Bj?rn Brandenburg <bbb at mpi-sws.org>
To: litmus-dev at lists.litmus-rt.org
Subject: Re: [LITMUS^RT] liblitmus: prop/cpp-safe
Message-ID: <4EC72673-0C56-4BE3-9EF1-86E88B1C3B99 at mpi-sws.org>
Content-Type: text/plain; charset=iso-8859-1
On Sep 27, 2013, at 8:07 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> I pushed a very minor change to the forward declaration of litmus_open_lock() in liblitmus's litmus.h (prop/cpp-safe). The declaration takes the parameter 'namespace'. Of course, C++ compilers can't handle a keyword used as a parameter name. This patch changes 'namespace' to 'name_space'. Note that this change is only limited to litmus.h. The use of variables named 'namespace' in the .c test files remains unchanged.
Merged, thanks for the patch!
- Bj?rn
------------------------------
Message: 2
Date: Fri, 4 Oct 2013 09:54:13 +0200
From: Bj?rn Brandenburg <bbb at mpi-sws.org>
To: litmus-dev at lists.litmus-rt.org
Subject: Re: [LITMUS^RT] PFair policy issue
Message-ID: <6AD44D48-4C3B-41C2-A531-CD59C6C4F084 at mpi-sws.org>
Content-Type: text/plain; charset=iso-8859-1
On Oct 2, 2013, at 2:50 PM, Mihai-Iulian Gheorghe <gheorghe at student.chalmers.se> wrote:
>
> I tried to run "rtspin", with the specified parameters, as requested, but no output is produced. Actually nothing is executed.
rtspin is not supposed to produce any output. It is just a simple testing utility that burns CPU time. Please check with top whether the appropriate amount of CPU utilization is generated.
Regards,
Bj?rn
------------------------------
Message: 3
Date: Fri, 4 Oct 2013 10:03:35 +0200
From: Bj?rn Brandenburg <bbb at mpi-sws.org>
To: kurian s <s.kurian at ymail.com>, litmus-dev at lists.litmus-rt.org
Subject: Re: [LITMUS^RT] Compilation problem with liblitmus
Message-ID: <2D380279-0D34-493D-8121-A0EB81A9E214 at mpi-sws.org>
Content-Type: text/plain; charset=windows-1252
On Sep 26, 2013, at 7:53 AM, kurian s <s.kurian at ymail.com> wrote:
> I'm getting following compilation errors while building liblitmus. This is after compiling kernel with litmus patch.
>
> bin/uncache.c: In function ?do_data?:
> bin/uncache.c:213:6: error: format ?%ld? expects argument of type ?long int?, but argument 3 has type ?int64_t? [-Werror=format]
> bin/uncache.c: In function ?do_max_alloc?:
> bin/uncache.c:308:3: error: format ?%lu? expects argument of type ?long unsigned int?, but argument 3 has type ?uint64_t? [-Werror=format]
> cc1: all warnings being treated as errors
> make: *** [uncache.o] Error 1
>
> I've no clue why this error is coming.
Hi Kurian,
the problem is probably due to a combination of missing casts in uncache.c and an overly picky compiler. I've pushed the below patch to the staging branch of liblitmus. Can you please check if that solves your problem?
Thanks,
Bj?rn
commit 1786cac8600789cef13968a73195d79745f18a68
Author: Bjoern Brandenburg <bbb at mpi-sws.org>
Date: Fri Oct 4 09:57:38 2013 +0200
Add explicit casts to uncache.c
Kurian S. reported the following errors:
>bin/uncache.c: In function 'do_data':
>bin/uncache.c:213:6: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'int64_t' [-Werror=format]
>bin/uncache.c: In function 'do_max_alloc':
>bin/uncache.c:308:3: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint64_t' [-Werror=format]
>cc1: all warnings being treated as errors
>make: *** [uncache.o] Error 1
This patch adds explicit casts to supress the warnings.
diff --git a/bin/uncache.c b/bin/uncache.c
index b6f6913..eb62583 100644
--- a/bin/uncache.c
+++ b/bin/uncache.c
@@ -210,7 +210,7 @@ int do_data(int do_uncache, int64_t* time)
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &end);
elapsed = timespec_to_us(timespec_sub(end, start));
printf("%s Time: %ldus\n", (do_uncache) ?
- "Uncache" : "Cache", elapsed);
+ "Uncache" : "Cache", (long) elapsed);
munmap((char*)data, size);
@@ -305,7 +305,7 @@ int do_max_alloc(void)
close(fd);
printf("Maxed out allocs with %d mmaps of %lu pages in size.\n",
- count, mmap_size/PAGE_SIZE);
+ count, (unsigned long) mmap_size/PAGE_SIZE);
return 0;
}
------------------------------
Message: 4
Date: Fri, 4 Oct 2013 11:55:19 +0200
From: Bj?rn Brandenburg <bbb at mpi-sws.org>
To: litmus-dev at lists.litmus-rt.org
Subject: Re: [LITMUS^RT] IPI vs. Cache Affinity
Message-ID: <22D0A154-E91E-4BF7-A7EB-8D793C33D5D3 at mpi-sws.org>
Content-Type: text/plain; charset=iso-8859-1
On Sep 28, 2013, at 1:23 AM, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> I certainly appreciate the simplicity of local scheduling. I will be investigating response times of cache heavy tasks under G-EDF/C-EDF over the next few weeks. I'll report back if I see any noticeable trade-offs between local-first vs. affinity-first scheduling.
Glenn,
I've pushed two patches to make the local linking optimization optional and to port it to C-EDF.
https://github.com/LITMUS-RT/litmus-rt/commits/prop/local-linking
The patches also fix a bug with release master (first reported & fixed by Felipe).
Please have a look whether these patches meet your requirements. If there are no objections, I'm going to merge them after the RTAS deadline.
Thanks,
Bj?rn
------------------------------
_______________________________________________
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 22, Issue 4
*****************************************
More information about the litmus-dev
mailing list