Hi,
SMARTT (System Metrics - Annotation Recording and Tracing Tool) is a
tool to capture and display system metrics data from the system. It's
mainly targeted for system metrics that are interesting for Graphics and
Multimedia WG for measuring and analyzing performance of their
tools/applications.
It has been designed and developed by Sudip Jain of Multimedia WG for
the Linaro 11.05 cycle [1][2][3], and packaged by Kunal Goel of
Developer Platform team [4].
A brief overview of the tool.
It is a distributed application where the systems metrics are gathered
by smartt-server running on the target system. At present, it gathers
metrics from perf (smartt-perf), top (smartt-top) and a GStreamer based
media player (smartt-player). A smartt-client app connects to
smartt-server to receive and display all system metrics in real-time.
It has been decided to continue to develop and maintain this tool for
Linaro 11.11 cycle. So inputs are required from the intended users of
this tool:
* the feature they would like to have it included in the tool
* the metrics data they would like to add
* design of the tool etc.
Please share your inputs and review comments on this tool.
Regards,
Avik
[1] 11.05 BP:
https://blueprints.launchpad.net/linaro-multimedia-wg/+spec/multimedia-lina…
[2] Spec:
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/Vali…
[3] git repo:
http://git.linaro.org/gitweb?p=people/sudip-jain/smartt.git;a=summary
[4] Package: https://launchpad.net/~goelkunal/+archive/multimedia
See https://wiki.linaro.org/OfficeofCTO/Status/2011-05-31 for relevant
links.
== Key Points for wider discussion ==
* Any tool related to tracking work progress during a development
cycle should be sufficiently integrated to our requirements and issue
management tool (Launchpad) - otherwise there will be need to handle
more than 1 tool.
* Debconf + Sprint: some contributors may be divided between the two
events. We should clearly indicate who needs to be participating to the
sprint to avoid confusion
== Team Highlights ==
* Blueprints: in place, check OCTO 11.11 schedules
* Public plans review: material prepared (check 11.11 public plans
review wiki page), comments from TSC requested
* Highlights
o Working on server work planning; will be like a whitepaper,
might turn into a wiki page; first draft expected next week
o Work on kernel merge window; Device Tree work went in!
o GPIO drivers moving from arch/arm/mach-*/ to drivers/gpio/
o PXE boot -- kexec based? Need to followup (OCTO-Grant
Likely, Kernel WG - Deepak) on state of kexec to see whether we need a
blueprint on this
o Updated Java plan - read more about the Optimized Java
Interpreter on the wiki link
* Work items sequencing is ongoing - Ilias
--
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
Hi,
Linaro Developer Platform team organises every week (Wednesday 14:00 -
18:00 UTC) an ARM porting Jam. The idea is to gather all developers together to
fix userspace portability issues across the board. The list of bugs
being worked on
is at launchpad:
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby…
Interested in making the software in Ubuntu run better on ARM? Join us on
the #linaro channel on irc.linaro.org today!
Cheers,
Riku
I am out of the office until 15/06/2011.
I am on vacation and will not be reachable by mail or phone.
Note: This is an automated response to your message "Does anyone care
about LSB on arm?" sent on 31/5/11 21:52:39.
This is the only notification you will receive while this person is away.
Hi there,
Some of you know about this already as it was discussed a bit at LDS,
but probably not very inclusively.
We have a slightly strange arrangement of projects on Launchpad, with
the main ones being "launch-control" and "lava". AIUI, Zygmunt really
wanted to call "launch-control" "dashboard" from day 1, but that was
clearly an overly generic name. Since then, we've come up with the
"lava" name to cover our automated validation efforts, but currently the
"lava" project just contains code to do with the validation farm in
Cambridge, which is only part of the story.
So. We have a plan to reorganize the projects like so (also documented on
https://blueprints.launchpad.net/linaro-validation-misc/+spec/linaro-platfo…):
- lava -- project group containing:
- lava-server -- contains the django settings file and templates
- this well mostly be extracted from what is lp:launch-control today
- lava-scheduler -- django application for scheduling jobs
- what exists for this is in lp:lava currently
- lava-dispatcher -- tool that runs tests on hardware
- this is also in lp:lava currently
- lava-dashboard -- django application for showing test results
- this is lp:launch-control currently
- lava-tool -- command line entry point and framework
- this actually exists already and has the right name!
- lava-dashboard-tool
- new name for launch-control-tool
- lava-test-tool -- plugin for lava-tool that adds commands for running tests
- new name and refactoring for abrek
- lava-auth-tool -- plugin for lava-tool that adds commands for authenticating against validation.linaro.org
- lava-scheduler-tool -- plugin for lava-tool that adds commands for interacting with the scheduler
- these last two don't actually exist yet
It's possible there are too many lava-tool plugins here, but we can see
how that goes when it comes to implementing those bits.
There will be a certain amount of churn and broken links during the
reorganization, so this is mostly a heads up and apologies in advance.
Bike shedding on the details of the rearrangement will probably be
ignored :)
I'll probably do this on Monday morning my time, which should be nice
and quiet.
Cheers,
mwh
On 27 May 2011 11:45, Deepak Saxena <dsaxena(a)linaro.org> wrote:
> On 26 May 2011 20:17, Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote:
>> My only comment is on:
>>
>> What We're Not Doing
>>
>> Integrating graphics drivers
>> ● Handled by vendor Landing Team
>>
>> I think aspects of this will need to be handled by the kernel team.
>> Especially with the work Jesse and the MM summit are proposing.
>
> Hi Zach,
>
> Clarification on the above point is that we will not be handling integrating
> binary blobs for the different SOCs. Any work that Jesse's team and
> upstream developers do on consolidating towards a single buffer
> management solution will certainly be integrated into the linaro-linux
> tree as it starts stabilizing.
We're going to need to chat about that. I'll need support for binary
blob integration from all teams. Overall I'm asking for each team
(Landing Teams included) to:
(Thanks to Michael Hope for suggesting this list)
1. Build the working group output and Android combinations with each
commit (CI)
* Build last-known-good Android with latest working group output
* Build latest Android with last-released working group output
* Build latest Android with latest working group output
2. Smoke test (CI/test farm)
* Load onto a board
* Run a test script
* Run 0xbench
3. Report any build or smoke test failures (CI)
4. Report any performance regressions (CI)
5. Document Linaro improvements in general and on Android, how to
build the component and how to get it.
6. Add benchmarks to showcase Linaro improvements.
7. Add tests to test functionality.
Some of this will be automated with Gerrit eventually. Until then
it'll be a manual process.
-Zach
