From Symbian Developer Community

Contents 1 Timing and Practicalities 2 Agenda 3 Participants 4 Previous Action Items 5 Material 6 Minutes 6.1 Company Capabilities 6.2 Proposed Improvement Schedule 6.3 Action Items 6.4 Topics 6.4.1 Company Capabilities 6.4.2 Proposed Improvement Schedule 6.5 Next Meeting Agenda 6.6 Next Meeting

Timing and Practicalities

Date: February 9th, 2010
Time: 16:00 - 17:30 (JST)
Location: Teleconference

Agenda

• Action item follow up
• Discuss and confirm participating company capabilities
• Open discussion

Participants

• Fujitsu: Koichiro Yamashita (Chair), Takahisa Suzuki
  
• ARM: Roberto Mijat
  
• DoCoMo: Nishihara, Kazuo Aoki, Kensuke Ueda
  
• STE: Marco Cornero
  

• Secretariat: Kiyoshi Miyazaki, Kouta Tanabe, Kyouji Suzuki, Jeremy Main

Previous Action Items

AI002-001: Update company capability tables
AI002-002: Report Company capabilities
AI002-003: Update benchmark information

Material

1. Resources available for SMP-WG (PDF)
2. SMP-WG Schedule Plan (PDF)
3. ARM's Hardware Performance Monitors Information (PDF) 2010-02-17

Minutes

During the meeting Company Capabilities and the Proposed Improvement Schedule were discussed.
If there are no objections to the capabilities and schedule items listed below, we should proceed in this order.

Company Capabilities

• Confirmed the capabilities of the responding participants.

• STE is currently performing application and MW level tests. Because there is a direct relation with a current development product, specific information can not be shared due to NDA issues. Information that can be shared will be shared.

• ARM has further list of benchmarks and comments to provide, including information on using the hardware Performance Monitor Unit. Summary to be presented offline. (AI003-004)

Proposed Improvement Schedule

• Presented the proposed schedule with respect to the official SF S^4 and S^5 release schedules.

• Planning to carry out two steps targeting S^4 and S^5

Step 1: S^4: Basic OS level, C/C++ lib basic level

Step 2: S^5: MW, Application framework evaluation

• In Step 1, basic SMP evaluation will be performed on Linux and S^4 simultaneously.

Basic system performance must be preserved.

Improvements proposals do not decrease basic performance.

Do not cause performance degradation for the SMP end-user.

• Investivation into the evaluation / measurement method of power consumption is required. (continue to examine)

Action Items

Action Item	Description	Responsible Party	Deadline
AI003-001	Share benchmark and power conservation information with WG	TI	2010-02-23
AI003-002	Verify Nokia's release schedule	Fujitsu	2010-02-23
AI003-003	Verify TI's hardware platform status	Fujitsu	2010-02-23
AI003-004	Update ARM's suggested benchmarks to WG Wiki	ARM	2010-02-23

Topics

The discussed topics are listed below.

Company Capabilities

Yamashita presented Material #1:

STE commented about their contribution capabilities:

• Focusing on SMP-safeness of the Symbian software stack
• SMP-enhancements, Identifying bottlenecks and removing them.
• Not optimizing specific applications.
• Can provide code to back to SF (within the constraints of the customer).
• STE is more focused on SMP-safeness and SMP-enhancements with some benchmarks used to do analysis.
• Can’t contribute to the wide spectrum of benchmarks. But can contribute to EMBC / ffMPEG-mt.

Asks three questions(Yamashita) to STE:
Q1: What is the meaning of SMP-safeness.
A: SMP-safeness is the capability of the OS and it’s software components, to run on a SMP system without crashing.

• Correctly uses synchronization primitives, uses or implements sectionality in a thread-safe way, without side effects (re-entrant).

• Symbian kernel is progressing very fast in terms of SMP-safeness, new functionality like load-balancing, there needs to be testing before you can be sure your software runs correctly.
• Crazy Scheduler good for testing software
• Source review to remove primitives that don’t work in an SMP system
• Remove the reliance on priorities to avoid race-conditions, disable interrupts to access exclusive parts of the software.
• Crazy scheduler is used to increase the level of testing with respect to SMP-safeness.

Q2: Does STE have a plan or capability to share test or benchmark test source code with the working group?
A: STE is focusing on three main sets of benchmarks:
1. Subset of 32Tests

• contain measurements of thread creating time, concurrency. These tests were adapted to SMP platform in cooperation their customer. This is what will be used in the beginning. The adaptation code could be added to the SF, Nokia should be asked about that.

2. EMBC Multibench

• Proprietary, not open source. Members of the consortium could possibly access the source code from EMBC, STE can not share their source code directly.
• The adaptation of EMBC to the Symbian platform, is ongoing.
• Need to identify how to share the port.

3. Multimedia benchmark

• ffMPEG-mt is used with Linux but a port to Symbian is still in planning. A lot of adaptation would be required.

Q3: using the U8500 board?
A: Can contact the right people to supply that information

ARM's comments about company capabilities.

• As the chip designer and many years of validation, benchmarking, porting and optimizing OS and software experience, the most effective way to contribute is though consultancy (within the framework of the SMP WG regular by-weekly calls).

TI's comments about benchmark experience.

• TI's experience with benchmarks is that a big benchmark like EMBC MultiBench is enough for a synthetic benchmark.
• For lower-level specific items, ad-hoc benchmarks were made. As for the Symbian SMP focused benchmarks, multi-media performance is critical.

Proposed Improvement Schedule

Yamashita presented Material #2:
Explanation of notation and coloring:

• Yellow part: Official release schedule
• Black Triangle: Already fixed schedule information
• Gray Triangle: Original schedule information

Q: Do you have any experience with low-level benchmarking? (Yamashita to ARM)

• Using LMBench to tweak hardware configurations rather than software performance.
• Linux is used as a benchmark reference, it has very good schedular performance.

The target low-level benchmark layers are:

• Memory access
• Cache activity
• Snoop systems
• Scheduling / dispatching
• Thread control system
• IPC
• Others

ARM comments about the low-level target layers:

• ARM-MP core have hardware performance monitoring units.
• 6 counters are available per processor, out of 58 events.
• There are SMP specific counters.
• There currently is no support for Symbian, but could be added or manually enabled using a debugger.
• All the information about the registers is available in the Cortex A9 MP Core technical manual on the ARM site.
• The registers a memory mapped registers on the system, can be accessed by reading and writing to a memory location.

Power consumption

• Currently the power consumption is being measured by measuring the current (draw?) of the power lines to the CPU.(STE)
• Measurement of amount of power consumption
  

Next Meeting Agenda

• Organize the proposed benchmark list
• Break-down schedule
• Other items

Next Meeting

• The next teleconference is February 23rd, 2010 (Tuesday)

Back to SMP-WG landing page

Comments

Sign in to comment…