LEG work in the user space level shall focus on enabling and optimizing those services that LEG members want to offer to their customers.
A vertical is the collection of components that are all required in the vertical sw architecture and stack to enable a given service. Verticals are aligned to the node view of a system - i.e. the code being executed by a given node in a hyper-scale server - rather than being aligned to the “horizontal” list of alternative components within the same technology or layer of the sw architecture - e.g. multiple web servers, multiple cache technologies, multiple file systems, etc.
There are four initial verticals required by LEG members:
- sponsors: Elsie + Kiko
assignees: Ard Biesheuvel, Steve McIntyre, Michael Hudson-Doyle
- start by enabling the LAMP stack and web front end, i.e. the classic Apache, MySQL, PHP, etc.
profile & optimize with focus on mem cache technologies as second phase
- mem cache technologies may actually become a separate vertical if needed
- sponsor: Facebook
- assignees: Owen Yamauchi + support from Fu Wei for LAVA
- start porting the interpreter then add bytecode optimizations one by one with incremental releases
- integrate key tests from Facebook into LAVA
- sponsors: Tim, Jeff
- Assignees: Steve Capper
- Hadoop Distributed File System
- MongoDB and other databases
- key value sets
- sponsors: Jon, Larry
While the engineering team gets formed and the work starts, the LEG Steering Committee continues in background in refining this document, adding more inputs, needs, priorities and then transferring into the engineering teams through the LEG-SC sponsors.
refers generally to an application service or framework that is deployed on a single ARM server or cluster of servers.
refers to the software stack required to enable a given workload. Note that this may be an overloaded term, since verticals could also refer to specialization of a given workload for a select market segment, such as financial services, public sector, manufacturing, etc.
an alternative term to the current usage of the term "verticals"
Align on the target workloads that will be interest to the broader LEG membership.
Start with a focus on achieving functional workload completeness (cast the net far and wide, resisting the temptation to reel it in too early). Then prioritize (value of the workload to broadest set of members). Don’t boil the ocean... select specific element to optimize, not all.
Build out Node-based view:
- Typifies what customers would deploy on a particular node. Note that these "workloads" are often made up of multiple services that may be centralized on "scale-up" capable nodes, or distributed on "scale-out" nodes. As a result, it's important to consider the stack-centric view and elements required to support each node of a given "workload"
Shows what would be used to build & deploy this complete stack at scale in a real world environment
- Provide a simple breakdown of the components, or typical elements, required for each and resultant cards to satisfy needs
- Functional Node → packages → gaps → cards
- Identify any common obstacles that will impact multiple workloads (eg. CRC instruction use in Hadoop)
- Identify the benchmarks/tools suites which will help validation of these workloads on ARM
Filter and prioritize the node-based views
- Key filter: Focus where ARM-based servers can provide a compelling value proposition vs traditional infrastructure
- Primary and secondary metrics for value creation with ARM-servers running these workloads
- Value to LEG membership (general vs niche)
- Customer/market interest
- 32-bit applicable
- Better addressed with 64-bit
- open source vs commercial implementations
- Man-years required to materially improve for ARM
Develop a single summary, or slide, that can be provided back to the LEG SC to help guide card development.
Apache Foundation leverage (consider as template for other community activities)
- Community outreach efforts
- Solicit/evangelize support
- Work for LEG to take on
Define testing process/model
- LAVA testing environment
- One potential alternative option is the HP Discovery Lab, assuming that partners consent to allow visibility and testing of (pre-release) systems by LEG members. (requires additional discussion and negotiation with involved parties)
- Perhaps we should clarify the extent of the testing that will be performed within LEG (please review for consistency with both the scope of LEG and the member preferences)
- Software validation (within the scope of LEG)
- Performance benchmarking (outside of LEG, through direct collaboration of SiP-OEM-Linux Distribution)
- The caveat is that some optimization may be left on the table if the feedback loop is absent or delayed between performance testing and the LEG development)
Template for LEG SC Sub-team
Define the use cases
- Small to large, sanitized customer examples
- Highlight implications for 32-bit vs 64-bit nodes
- Highlight opportunities for ARM value-add
- Define the node implications of the workload
- Are there multiple agents, services, or elements of the workload?
- Hybrid-node implications
- Do the requirements differ for these elements, such that some may find more value on an ARM node than others?
- Does this imply a v7 or v8 dependency, or rather an x86 and ARM hybrid use case for the most compelling solution?
- Define the applications/frameworks typically used for this workloads
- Leave dependencies and packages to be identified by Engineering
- Identify possible outreach opportunities
- Solicit/evangelize support - where can the community do work to help us here?
- Identify the work for LEG to take on, based on architectural dependence - (Develop in collaboration with Engineering?)
LEG/Engineering/verticals (last modified 2013-02-03 22:53:29)