Thomas Canhao Xu | Hannu Tenhunen | Pasi Liljeberg
Embedded Software System Architecture for MyGoogle-on-Chip
TUCS Technical Report No 922, November 2008
Embedded Software System Architecture for MyGoogle-on-Chip Thomas Canhao Xu
University of Turku, Department of Information Technology Joukahaisenkatu 3-5 B, 20520 Turku, Finland
[email protected]
Hannu Tenhunen
University of Turku, Department of Information Technology Joukahaisenkatu 3-5 B, 20520 Turku, Finland
[email protected]
Pasi Liljeberg University of Turku, Department of Information Technology Joukahaisenkatu 3-5 B, 20520 Turku, Finland
[email protected]
TUCS Technical Report No 922, November 2008
Abstract This document presents a planned structure of embedded software system for myGoogle-on-Chip. MyGoogle-on-Chip is a special case of Network-on-Chip, which is a method of placing hundreds or even thousands of cores on one chip. MyGoogle-on-Chip is an embedded personal hand-held multimedia storage system. With the Network-on-Chip architecture, myGoogle-on-Chip will support associative search methods. Software support, especially system software support for the chip hardware is critical. We will discuss some of the core aspects of myGoogle-on-Chip software system, including its generic system software architecture, its scheduler (distributed control system), its storage and file system, its indexing and its database associative search system.
Keywords: embedded software, Network-on-chip, scheduling, multiprocessor, indexing, database, file system
TUCS Laboratory Computer Systems Laboratory
1
Introduction
MyGoogle-on-Chip, a special case for Network-on-Chip (NoC) [1], will be developed for the multimedia player market. The demand for flash based and hard drive based multimedia players will more than double in the next four years. A recent report said that shipments will jump from 140 million units in 2005 to 286 million by 2010 [2]. The increasing demand is not only for multimedia mass storage systems, but also for integrated associative search methods for large audio, video, picture, text document and other files. Besides traditional multimedia content, myGoogle-on-Chip is planned to store indexed personal information such as email and instant messages service. These contents may take terabytes. Currently, there are some industrial state-of-the-art cases of personal handheld multimedia devices such as Apple iPod and Microsoft Zune.
Figure 1: iPod and Zune Here is a compare table of different versions of iPod and Zune as of 11/2009: Table 1: iPod 32 Size 110x62x8.5 Weight 115g Storage 32GB Flash Interface USB/Wifi CPU ARM11 412M Power A-36hr/V-6hr
Comparison of iPod and Zune iPod 120 Zune 16 104x62x10.5 91x41x8 140g 47g 120GB HDD 16GB Flash USB USB/Wifi ARM ?M ARM11 532M A-36hr/V-6hr A-24hr/V-4hr
Zune 120 108x61x13 128g 120GB HDD USB/Wifi ARM11 532M A-30hr/V-4hr
Both iPod and Zune use hard disk drives and flash memories and they are 1
based on single processor System-on-Chip technology. Hard disk drive versions are large, heavy, expensive and fragile; while flash versions are small, light and can resist some degrees of impact. For now, hard disk drives can still provide better capacity and better performance than flash drives. Besides storage, iPod and Zune suffer from limited processing ability; their processors are single and slow and can not process large videos and pictures in a limited time. High-definition videos and movies that have 720p or even 1080p resolution can have an uncompressed data-rate of 210 to 932 megabits per second, and a compressed data-rate of 25 to 100 megabits per second [4]. Users usually have to download videos and pictures specially encoded for these platforms if they do not encode themselves as none of current multimedia hand-held devices can decode such data-streams. Indexing and searching is another problem: people have to organize their multimedia contents themselves, when there are tens of thousands of files containing not only music, movie, pictures, but also documents and emails, everything would be a problem. Apparently, for future hand-held multimedia devices, iPod and Zune are not good enough. MyGoogle-on-Chip will be mainly based on smart solid state disk (SSD), designed to become a storage device for the future. Smart SSD has better capacity, better flexibility, better performance and better power consumption than traditional hard disk drives. It is currently being developed by cooperation such as Sandisk, Samsung and Intel. SSD devices can replace traditional hard disk drives, when the technology and market ready. Besides smart SSD, myGoogle-on-Chip has another advantage as well - the multiprocessor. MyGoogle-on-Chip will be based on a distributed multiprocessor architecture, which will increase computational ability compared to single processor architecture. With these, myGoogle-on-Chip can support extensive associative search on hand-held multimedia devices. In conclusion, devices based on myGoogle-on-Chip technologies is planned to have: • Multiprocessor System-on-Chip (MPSoC) architecture that will bring better processing power which can deal with high data rate high definition video streams, as well as high resolution images. • Smart multiprocessor scheduler that can identify multimedia data streams and power-awareness. • Better storage capacity, lower power consumption and better disk readwrite-seek performance due to the usage of smart solid state disk. • Distributed indexing and associative search method that can process terabytes of data. A typical architecture of myGoogle-on-Chip looks like this: 2
SSD/ Generic processor
SSD/ Generic processor
SSD/ Image processor
SSD/ Image processor
Controller processor
Network Connection
Input
Output
SSD/ Video processor
SSD/ Video processor
SSD/ Video processor
SSD/ Video processor
Network interface adapter
Other devices
Figure 2: Typical architecture of myGoogle-on-Chip. The controller processor runs the main operating system which is responsible for scheduling and controlling. There are audio, video, image and generic processors and SSDs, which are specially optimized for certain tasks. All processors/modules are connected with a network interconnection.
2
Generic System Software Architecture
The system software for myGoogle-on-Chip should provide device interoperability (including new user-interface technology) and data management operation. It should also provide higher levels of programming models such as an Application Program Interface (API), system user library files and dynamic link library files. It will make a whole operating system by putting everything all together [23]. Furthermore, all these must have good support for highly parallel Network-on-Chip architecture. The design challenges concerning the myGoogle-on-Chip software architecture include: 3
• Multiprocessor scheduling which is aware of multimedia contents, to classify, identify and make decisions about the data stream. It will be explained in more detail in section three. • A file system for smart solid state disk, supporting parallel operation. It must be power-aware as well as flash-life-aware. It will be explained in more detail in section four. • A parallel distributed indexing mechanism which is capable of utilizing multiprocessor and multistorage of myGoogle-on-Chip architecture. It will be explained in more detail in section four. • An associative database search engine, with all indexed meta-data of multimedia files stored in a database for future associative searches. It will be explained in more detail in section four. • A power control mechanism. The following figure is a draft myGoogle-on-Chip system software architecture:
4
User input (touch screen/ Keypad/ Gravity/ Voice...)
Network device interconnection (Bluetooth/ Wifi/ WiMAX…)
Output (Audio/Video/ Picture/ Document)
Input/Out put System
User interface process
Discovery process
Multimedia content processing process
Quality of service control
MyGoogle-on-Chip Embedded Operating System Power management process
Multiprocesso r Scheduler
Indexing process
Smart SSD storage
Multiproce ssor
Hardware/ Storage
Database engine
Multimedia files
Battery
Database
Figure 3: Software architecture of myGoogle-on-Chip. The upper level is the I/O System, the lower level is the multiprocessor, the multistorage and the battery. There are eight main parts of the middle operating system. The “User interface process” is responsible for receiving user input and deal with outer network device discovery. The “Multiprocessor scheduler” is responsible for processor scheduling and coordinating other parts, including power management and quality of service. The “Indexing process” and “Database engine” are responsible for indexing files and implementing distributed associative search method, as well as file system for smart SSD. The “Multimedia content processing process” is responsible for decoding video, audio, picture and document, the decoded contents will be output to the display. 5
3
Multiprocessor Scheduling
Network-on-Chip is a multiprocessor architecture with tens or even hundreds of resource nodes, or processors. Efficient multiprocessor schedule algorithm is therefore critical for the situation. Processors in myGoogle-on-Chip should also be functionally diversified. A specially designed processor for audio stream, a specially designed processor for video stream and a specially designed processor for pictures are the most important ones, because processors designed for specific applications are much faster than general purpose processors [5]. For these reasons, a distributed control and data management system, a “multiprocessor scheduling mechanism” for the controller processor, to classify the data stream and send to the corresponding sub-processor, is critical for the myGoogleon-Chip architecture. The scheduler should be power-aware, as limiting energy consumption is critical for a battery driven embedded device, especially when the device has multiple processing and storage units. Operating system scheduling is the method by which threads, processes or data flows are given access to system resources [11]. In the case of myGoogle-on-Chip, the system resources are the multiprocessor and the multistorage. Scheduling is usually done to load balance a system effectively or achieve a target Quality of Service. The need for a better or more suitable scheduling algorithm arises from the requirement for most modern systems to perform multitasking (execute more than one process at a time), especially on multiprocessor systems. For a Networkon-Chip architecture, the scheduling algorithm should be able to multiplex, to transmit multiple data flows simultaneously. One of the simplest scheduling algorithms is “round-robin” [11], in which each process is given equal time, for instance 100ms, in a cycling list to use a certain system resource. Round-robin scheduling is absolutely fair, but lacks an advanced control mechanism. When system background process A executes for 100ms, a CPU starving process B executes for 100ms and a user interface interaction process C executes for 100ms, the result maybe some lag in system response which does not give a good user experience. Furthermore, for real-time systems, 100ms maybe too long for mission critical processes. A more advanced scheduling algorithm would take into account process priority, or the importance of the process. This mechanism allows some processes to use more time than other processes, and others less. However no matter which scheduling algorithm is running, only one process can be running at one time for a single processor system. We will not feel a lag because of the relatively high priority of user interface interaction processes. MyGoogle-on-Chip will be a based on a multi-core processor architecture, or chip-level multiprocessor (CMP). It will combine 32, 64 or more independent process cores into a single package composed of a single integrated circuit. Multi-core architecture in MyGoogle-on-Chip is different from modern dual-core or quad-core processors since it is using a network connection rather than bus 6
connection. Cores in a multi-core processor such as the Intel Core 2 architecture may share a single coherent level 2 cache [6], or in the case of Intel Core i7 and AMD Phenom architecture they may have separate stand-alone level 2 caches with another coherent level 3 cache [7][8]. Different cache implementation will affect overall performance greatly, so it must be considered in MyGoogle-on-Chip architecture [9]. The processors share the same interconnection to the other parts of the system as well. A processor system with n cores is effective when it is presented with n or more processes or threads concurrently. The amount of overall performance gained by the use of multi-core processor architecture depends on the problem being solved and the scheduling algorithms used [28]. The application field of myGoogle-on-Chip enables massive parallel computing: high definition movies can distribute each frame into each processor; multiple indexing programs can run simultaneously, release full power of 32 or 64 cores [24]. But if without the help of a suitable scheduling algorithm, there will be only limited speedup, if at all.
3.1
Linux scheduler
The Linux kernel has some multiprocessor scheduling support, such as O(n), O(1) and the recent Completely Fair Scheduler (CFS) [14][15].
3.1.1
The O(n) scheduler
At the time of 2.4.x series Linux kernel, the scheduler is called O(n) scheduler because of the scheduling algorithm is implemented with complexity of O(n). The scheduling algorithm will take longer time to schedule a process when there are more processes, so it has a significant limitation when many tasks are active. So the result would be: when the system is at very high load, the processor can be consumed with scheduling and devote very little time to the processes. The O(n) algorithm lacks scalability. The O(n) scheduling algorithm also uses a single run-queue for all processors in a symmetric multiprocessing system (SMP). This means a process or thread could be scheduled on any processor. It is good for load balancing but the resource consumption costs during process switch between processors could be huge, especially when there are too much data in register and cache. Besides a single run-queue, the O(n) scheduler uses a single run-queue lock. In SMP systems, the act of choosing a task to execute locked out any other processors from manipulating the run-queues. The result is that idle processors awaiting release of the run-queue lock and thus system overall performance is affected badly, resulting poor scalability. 7
3.1.2
The O(1) scheduler
The O(1) scheduler introduced in Linux kernel 2.6 series was designed and implemented by Ingo Molnar. The O(1) scheduler resolves some major problems found in the earlier O(n) scheduler. It has better support for SMP systems, multiple CPUs or cores are better to execute individual tasks simultaneously. The prior O(n) scheduler uses big-lock mechanism which means that when a CPU is choosing a task to dispatch and the runqueue was locked by the CPU, other CPUs have to wait. The O(1) scheduler has a lock on each runqueue, resulting all CPUs able to schedule tasks without contention from other CPUs [10]. Besides the novel lock mechanism, the O(1) scheduler introduced a load balancing mechanism in SMP systems: When tasks are created in a SMP system, they’re placed on a given CPU’s runqueue. Generally speaking, one can not know whether a task will be short-lived or it will run for a long time. But as time passed, to maintain a balanced workload across CPUs, work can be redistributed, taking work from an overloaded CPU and give it to an underloaded one. The O(1) scheduler checks each CPU every 200ms to see whether the loads are unbalanced; if they are, the scheduler performs a cross-CPU balancing of tasks. Another advantage of the Linux O(1) scheduler is that it allows process preemption. This means a process with lower priority will not execute while a process with higher priority is ready to run. The scheduler preempts the process with lower priority, places the process back on its priority list, and then reschedules. Process preemption will allow better desktop user responsiveness and interactive communication performance [15]. 3.1.3
The CFS scheduler
The Linux 2.6.23 kernel comes with a modular scheduler core and with a new scheduler called Completely Fair Scheduler (CFS), which is implemented as a scheduling module [12]. The design of CFS is quite different from O(1) and O(n) scheduler, it does not use runqueues, and it uses a time ordered Red-Black tree to build a time line of future task execution. CFS uses nanosecond granularity accounting and does not rely on any jiffies or other HZ detail, thus the CFS scheduler has no notion of time slices as the original schedulers have and thus has no heuristics [13]. CFS tries to run the task with the gravest need for CPU time, this helps to assure that every process gets its fair share of CPU. And CFS supports group scheduling as well: it will bring better fairness to a multi-user environment. Take an example with two users running jobs on a computer. User A has five jobs running, user B has twenty jobs running. Group scheduling makes CFS to be fair to user A and user B, that is to say both users get a 50 percent share of CPU time. User B would use his 50 percent share to run twenty jobs and user A takes another 50 percent share to run five jobs [16]. CFS is quite a new scheduler, it will require more time to be mature [21]. 8
3.2
The scheduler for myGoogle-on-Chip
None of current state-of-the-art scheduler has the ability of classification data stream, no matter in Windows or in Linux. For myGoogle-on-Chip, a scheduling algorithm is quite different from the traditional ones, because of the following reasons: • The scheduling algorithm should be able to do data stream identification, classification, prioritize and distribution. • The scheduling algorithm should also support Quality of Service. • The scheduling algorithm should be power aware because of the multi-core nature of the myGoogle-on-Chip architecture. Thus a more suitable efficient scheduling algorithm for MyGoogle-on-Chip requires multimedia scheduling, Quality-of-Service and power-awareness. 3.2.1
Multimedia scheduling
Multimedia scheduling means: first multimedia processes should have higher priority than other normal system processes, second in-network multimedia dataflow classification, identification and distribution mechanism must be applied in the scheduling algorithm, third the mechanism should be energy efficient for battery driven devices [25][26]. Microsoft Windows Vista includes a Multimedia Class Scheduler Service (MMCSS), which is used to provide a better multimedia playback experience. The MMCSS will manage the CPU priorities of multimedia programs so that unpleasant hiccups during playback could be lighten or even eliminate. The MMCSS will try to monitor system process activities. If it finds some applications such as Anti-Virus Software or Web Browser which consume too much CPU time, it will increase the priority of multimedia applications and decrease the priority of other non-system processes. Besides, Microsoft Windows Vista introduces two new methods of prioritize I/O as well. I/O prioritization can make multimedia applications have a preference by priority on individual I/O operations and reserve I/O bandwidth for multimedia data-streams [31]. However MMCSS has a side effect, it will result a poor networking performance and Microsoft is trying to solve it [32]. Lessons must be learned from Vista, so that we can make a better multimedia scheduling mechanism for myGoogle-on-Chip [19]. Another problem comes to the Asymmetric Multiprocessor(AMP) architecture of myGoogle-on-Chip. For best effort of processing different stream of video, picture and audio, processors specially optimized for certain application is required, the scheduler will make the decision [20]: 9
Incoming data stream
Generic processor
Image processor
Scheduler
Generic processor
Video processor
Image processor
Video processor
Video processor
Video processor
Figure 4: Multimedia scheduling for myGoogle-on-Chip. The scheduler identifies, classifies and makes decision to incoming data streams. Data streams are directed to different sub-processors. 3.2.2
Quality of Service
Network-on-Chip is a novel chip design method that brings packet switch network to multi processor chips interconnection rather than the old-fashioned bus interconnection. The nature of packet switch network makes traffic engineering, as known as Quality of Service (QoS) possible. It should be implemented into the scheduling system. QoS means to make control of resource reservations rather than the achieved service quality. Services with that kind of control will able to provide different priority to different applications, users, or data flows, or to guarantee a certain level of performance to a data flow [33][18]. For example, a required bit rate, delay, jitter, packet dropping probability or bit error rate may be guaranteed [17]. MyGoogle-on-Chip is designed for massive storage and associative search in a Network-on-Chip environment, thus it requires the implementation of QoS. The implementation should be able to distinguish different data flows, identify them, classify them and make decision according to the routing protocol. In a packet switch network, many things can happen to packets as they travel from origin to destination, resulting problems in network communication such as dropped packets, delay, jitter and out-of-order delivery, thus errors may happen. Network protocol specially designed for myGoogle-on-Chip is required. The protocol should 10
not only consider different mesh, bandwidth, scalability, deflection count, network delivery time, latency, throughput, link utilization, but also carry the tag of QoS. Making evaluation of application data dependability, reliability and integrity. Application Layer
Transportation Layer
Network Layer
Datalink Layer
Physical Layer
Figure 5: Protocol model. A five-layer model similar to Open System Interconnection Reference Model (OSI/RM) that has seven layers.
Network Layer Source Address
Destination Address
Data flow identification tag s Data flow traffic priority tag
Payload length / Options
Figure 6: Network layer that supports data flow QoS. Data flow identification tag will identify the incoming data flow is a video or an audio. Data flow traffic priority tag will set a number of priorities of the data flow. There is an options segment for further tag information.
4
Storage and file system
MyGoogle-on-Chip is going to use Smart Solid State Disk, which is a better type of SSD than current state-of-the-art SSD. Smart SSD will bring more processing power into memory systems and will provide new embedded data management mechanism for embedded storage systems. A specially designed file system is required to fit the nature of smart SSD rather than traditional mechanical hard disk file system. A file system will provide 11
the method for storing and organizing computer files and the data they contain to make it easy to find and access them, for embedded devices it should have low power consumption. File systems may use a data storage device such as a hard disk or a solid state disk and involve maintaining the physical location of the files, they might provide access to data on a file server by acting as clients for a network protocol. There are some aspects worth noticing of the myGoogle-on-Chip architecture storage sub-system because of the smart solid state disk [22].
4.1
Solid state disk
Solid state disk drive is a data storage device that uses solid state flash memory [3], such as Single-Level Cell (SLC) or Multi-Level Cell (MLC), to store persistent data. It has limited write and erase cycles, the flash memory cells will often wear out after thousands of write cycles for MLC, and may up to several hundred thousand write cycles for SLC, while high endurance cells may have endurance up to several million write cycles. In fact log files, file allocation tables and other commonly used parts of the file system are accessed very often in traditional hard disk file systems. Special file systems or firmware designs can not eliminate this problem but make it better by wear leveling - spreading writes over the entire device, rather than rewriting files in place.
Figure 7: Traditional hard disk drive and novel solid state disk drive. Although they have the same physical size and outer appearance, Solid state disk drive does not use any mechanical devices. Solid state disk drive tend to have slower write speeds, as erase blocks on flash-based SSDs generally are quite large, they are far slower than conventional disks for random writes and therefore vulnerable to write fragmentation, and in some cases for sequential writes. SSDs based on RAM and batteries do not suffer from this problem, they are much expensive. 12
4.2 4.2.1
File system for Smart SSD In consideration of disk life time
A solid state disk flash file system is a file system designed for storing files on flash memory devices. Despite a block layer device can emulate a disk drive, hence a hard disk file system can be used on a flash device, but this is not the optimal implementation. The fact is, traditional file systems, such as File Allocation Table (FAT) and File Allocation Table 32 (FAT32), are widely used in flash devices. FAT and FAT32 suffer from limiting flash life cycle because of unwise write strategy. A file system designed for SSDs must support wear leveling, which will spread out writes evenly. Log-structured file systems have the desirable properties for a flash file system. Such file systems include Journaling Flash File System version 2(JFFS2) [27] and Yet Another Flash File System(YAFFS) [29]. 4.2.2
In consideration of database
The file system should be optimized for database operations because of database indexing and associative search. Database-based file system is a new concept of file management. In addition to traditional file system hierarchical structure, files in myGoogle-on-Chip are identified by their characteristics, like type of file, title, author, year, bit-rate or some other meta-data. In database management systems such as MySQL and Oracle, “raw” file systems can be used. A raw file system is a special kind of file system that operating system handles the right of operating disk blocks directly to database management system. That is to say the database management system bypasses the operating system’s caches and buffers, it can use the disk directly, enabling them to manage how data is cached, rather than deferring this task to the operating system’s file system. 4.2.3
In consideration of data distribution
The design nature of myGoogle-on-Chip enables distributed storage in a network, the file system should support that nature. There are two levels of file system that support data distribution: distributed file system or clustered file system. A clustered file system is a storage file system which can be shared, that is to say concurrently accessed for reading and writing, by multiple computers. Take the myGoogle-on-Chip case as an example, such computers are resource nodes connected by internal networks. The myGoogle-on-Chip architecture is a small scale of storage area network (SAN). There are different architecture implementations to a clustered file system. Some distribute file information across all the nodes in a cluster, which is called a fully distributed cluster file system. Others utilize a centralized meta-data resource node, while data are stored across all other 13
nodes. Both achieve the same result of enabling all nodes to access all the data on a shared storage device. A distributed file system is a file system that allows access to files located on another remote host as though working on the actual host computer. Take the myGoogle-on-Chip case as an example, such computers are resource nodes connected by internal networks. One node has to access other nodes’ storage via networking protocol. A distributed file system may include facilities for transparent replication and fault tolerance. When a limited number of resource nodes in a myGoogle-on-Chip network file system go off-line, the system continues to work without any data loss. 4.2.4
Design requirements for Smart SSD file system
We have to develop a novel file system for myGoogle-on-Chip based on Smart SSD. In conclusion, we must pay attention to these design points: • The file system should be designed for the nature of Solid state disk, to maximize its life expectancy. • The file system should have distributed nature, since data are stored in different flash memory of SiP. • The file system should have better support of multimedia files, indexing and database associative search. • The file system should have strong failure recovery mechanism, since power loss is common in battery powered embedded devices. • The file system should put more data into memory, getting better access performance and less power. • There should be a block layer I/O scheduler specially designed for myGoogleon-Chip file system.
5 5.1
Distributed indexing and database storage Indexing
Since tens of thousands multimedia files would be stored in myGoogle-on-Chip, a good search engine that can deal with these contents is very important. Furthermore multimedia content preview is also a very important function: people want to preview their pictures in thumbnail as fast as possible, so do video, sound and document. One of the best ways to do this job is to have a distributed query processing mechanism, which can fully make use of the multiprocessor nature of Network-on-Chip. Here shows a concept figure of the indexing system: 14
Power monitor
User interface
Indexing controller
Embedded Operating System Meta-data crawler
Database
Meta-data crawler
Distributed query
Meta-data crawler
Files
Smart solid state disk storage
Database indexing storage
Figure 8: Indexing. The indexing controller in the operating system will spawn tens of Meta-data crawlers simultaneously. The crawler will index multimedia files concurrently. The indexing controller will send indexed data to database for further distributed query. The power monitor is designed to ensure the indexing controller power-aware. Index data, including text, audio, video and picture, store the indexed data to SSD and implement user friendly associative search are core requirements of myGoogle-on-Chip. There are some requirements for the indexing algorithm: • It runs at the background and monitors changes of files. • It should be distributed to different resource nodes. • It should be power aware, running at low battery power is not a wise movement. • It should have different Quality of Service against different files and passes. There are some mature state-of-the-art search systems such as Windows Search and Google Desktop. Another open source desktop search software under the Linux system is called Beagle, which is based on Apache Lucene indexing and search system. Beagle can act as a Linux desktop-independent service which transparently and unobtrusively keeps track of ones data and provides searching 15
and indexing capabilities. Provided by Apache Lucene, Beagle can track changes to data and index in real time, and files are immediately indexed when they are created; are re-indexed when they are modified; and are dropped from the index upon deletion. Beagle can index Emails upon arrival, can index IM conversations as chatting, and can index web pages as viewing. Beagle can index nearly all file formats, when Beagle is searching, all of the text and meta-data contained in the files are extracted. Beagle has some network features, it can search remote beagle services in the network, so collaboration and sharing is possible. Beagle has a scalable and high performance indexing method. It is estimated that Beagle can index over 20MB per minute on a Pentium M 1.5GHz CPU, it requires only 1MB heap RAM, its incremental indexing is as fast as batch indexing, while the index size is roughly 20-30% the size of text indexed [35]. The Apache Lucene engine in Beagle has also powerful, accurate and efficient search algorithms. It can support ranked searching, different powerful query types such as phrase queries, wild-card queries, proximity queries and range queries. The engine can support fielded searching, date-range searching, multiple-index searching as well, and it allows simultaneous update and searching. It looks like that Beagle and Apache Lucene are powerful, but in consideration of myGoogle-on-Chip specifications, They have some problem. The first problem is the indexing engine itself. The Apache Lucene engine is based on Java. Although it brings the ability of cross platform and architecture, the language is considered resource consuming. Java applications are typically compiled to bytecode that can run and only can run on a Java virtual machine (JVM), however the additional JVM layer between the engine and the operating system will make programs slower, especially on resource constraint myGoogle-on-Chip systems. The second problem comes to the Query-Parser of Lucene. It is not thread-safe, hence running the Query-Parser on a multiprocessor platform such as myGoogleon-Chip will need modifications to prevent race conditions, deadlocks, live-locks and starvation. The third problem is that the Lucene engine does not have a good support of making database as an indexing storage, the performance is very low and since it is not suitable to use a database to store indexed data, associative search method is quite limited in Lucene. We have to overcome the above-listed problems, and develop a new indexing system suitable for myGoogle-on-Chip.
5.2
Database storage and associative search
After indexing, or say when it is indexing, Relational Database Management System (RDBMS) is the best choice for organizing huge amount of indexed data. However there are some problems concerning: • For embedded purpose, the database should be quite small and efficient. 16
• The database should support multiprocessor architecture, hence user queries processes could be distributed. • The database should be able to store indexed multimedia data, for example a clip of audio or video and a thumbnail of picture. For the above-mentioned reasons, we need to focus on SQLite, the de-facto embedded relational database management system, and make some modifications to fit the myGoogle-on-Chip architecture. SQLite is a RDBMS contained in a four hundred kilobytes small C programming library (version 3.5.9) and a thirty kilobytes command line interface (version 3.5.9). SQLite implements the SQL-92 standard for SQL, including three of the ACID requirements for database transactions: Atomicity, Isolation and Durability. SQLite supports multiple tables, trigger, index, transaction, view and limited complex queries. SQLite does not support referential integrity constraints, it does not satisfy a common consistency requirement [30]. Here show the database system architecture of SQLite:
Application Program Interface
Preprocessor/Parser
Code Generator
SQLite
Virtual Machine
B Tree
Page cache
Operating system interface
Figure 9: SQLite system architecture. When user applications send request via API, the preprocessor and parser will parse the command and the code generator will generate codes running at the virtual database engine (VDBE). B tree and page cache optimization together can make less disk access. 17
Unlike client-server database management systems, the SQLite engine is not a standalone process which the program communicates with. The SQLite library is already linked inside the program, becoming an integral part of it. The SQLite main program makes simple function calls which reduces latency in database access because of function calls are more efficient than Inter Process Communication (IPC). The entire database of SQLite is stored on a host machine as a single cross platform file. The entire database file must be locked at the beginning of a transaction due of the design. The previous industrial implementation of SQLite including [34]: • Mozilla Firefox, which uses SQLite to store its bookmark system and web access history. When user is typing in the address bar, Firefox calls SQLite to search the database and return some “associative records”. • Apple Mac OS X, which uses SQLite as a storage of any sort of data organized by the relational entity-attribute model in its “Core Data” system. • Google applications, including Google Desktop for Macintosh, Google Gears and Android. Mainly for the full-text search subsystem. SQLite have to be improved for myGoogle-on-Chip architecture, it must support multiprocessor and distributed environment and be efficient on power-aware embedded systems.
6
Conclusion
MyGoogle-on-Chip is expected to be a very hot topic in the future, no matter in academicals or in market. It is expected to be the next generation hand-held personal multimedia device. MyGoogle-on-chip will be based on smart SSD and multiprocessor, it will enable integrated associative search method. Hence research its system software architecture, and how the system software interacts with hardware, is very important. This paper shows a planned architecture of myGoogle-on-Chip system software, its implementation and research challenges. We showed a generic system software architecture of myGoogle-on-Chip and studied the design challenged concerning its software architecture. We studied state-of-the-art scheduling algorithm gave some suggestions to the scheduler of myGoogle-on-Chip (the distributed control system). The scheduler should support data stream identification, classification, prioritization and distribution, it should support Quality-of-Service as well and power-awareness. We can learn from Microsoft Windows Vista’s MMCSS and improve it. The file system should be specially designed for myGoogle-on-Chip. Experiences told us that the file system must consider SSD life time, database operations, 18
file data and meta-data distribution. A block layer I/O scheduler for the file systems is required as well. We gave a preliminary indexing mechanism for myGoogle-on-Chip. The distributed indexing system runs at the background and monitors changes of files, it will limit its activities at low battery power. To support associative search method in a multiprocessor and multistorage environment, an embedded database system optimized for that environment is required. We have found limitations of industrial state-of-the-art database system and are going to improve it in the future. Further research will deepen every aspect.
7
Acknowledgment
I would like to thank TUCS for funding my research. I would like to thank everyone who cares about me, especially my parents and my workmates. I would like to thank Professor Helena Karsten for the correction of this paper.
19
References [1] Axel Jantsch and Hannu Tenhunen. Networks-on-Chip, Kluwer Academic Publishers, 2003 [2] Study: Market for MP3 players to double http://www.macworld.com/article/50639/2006/05/study.html
by
2010,
[3] Solid-state drive, http://en.wikipedia.org/wiki/Solid-state drive, November 2008 [4] Ben Waggoner. Understanding HD Formats, http://www.microsoft.com/windows/windowsmedia/howto/articles/UnderstandingHDFormats.aspx, November 2008 Microsoft Corporation, January 2004. [5] Scheduling algorithm, http://en.wikipedia.org/wiki/Scheduling algorithm, November 2008 [6] Intel. Intel Core2 Duo Processor E8000 and E7000 Serie Datasheet, http://download.intel.com/design/processor/datashts/318732.pdf Intel Corporation, October 2008. [7] Intel. Intel Core i7 Processor Extreme Edition and Intel Core i7 Processor Datasheet, Volume 1, http://download.intel.com/design/processor/datashts/320834.pdf Intel Corporation, November 2008. [8] AMD. Family 10h AMD Phenom Processor Product Data Sheet, http://www.amd.com/usen/assets/content type/white papers and tech docs/44109.pdf AMD Corporation, November 2007. [9] Tom’s Hardware. Alle Benchmarks Desktop CPU Charts Q3/2008, http://www.tomshardware.co.uk/charts/desktop-cpu-charts-q32008/benchmarks,31.html Tom’s Hardware, November 2008. [10] O(1) Scheduler, http://en.wikipedia.org/wiki/O(1) scheduler, November 2008 [11] Abraham Silberschatz, Greg Gagne and Peter Baer Galvin. Operating System Concepts, Seventh Edition, John Wiley & Sons. Inc, 2005. [12] Completely Fair Scheduler, http://en.wikipedia.org/wiki/Completely Fair Scheduler, November 2008 [13] Jeremy. Linux: The Completely http://kerneltrap.org/node/8059, November 2008 20
Fair
Scheduler,
[14] Josh Aas. Understanding the Linux 2.6.8.1 CPU Scheduler, http://joshaas.net/linux/linux cpu scheduler.pdf Silicon Graphics, Inc.. 2005. [15] M. Tim Jones. Inside the Linux http://www.ibm.com/developerworks/linux/library/l-scheduler/, ber 2008
scheduler, Novem-
[16] Avinesh Kumar. Multiprocessing with the Completely Fair Scheduler, http://www.ibm.com/developerworks/linux/library/l-cfs/, November 2008 [17] IPv6, http://en.wikipedia.org/wiki/IPv6, November 2008 [18] Zhonghai Lu and Mingchen Zhong and Axel Jantsch. Evaluation of Onchip Networks Using Deflection Routing, Proceedings of GLSVLSI 2006, April 30, 2006 - May 2, 2006. [19] Yoav Etsion, Dan Tsafrir, and Dror G. Feitelson. Process Prioritization Using Output Production: Scheduling for Multimedia, ACM Transactions on Multimedia Computing, Communications and Applications, Vol. 2, No. 4, November 2006, Pages 318-342. [20] Tong Li, Dan Baumberger, David A. Koufaty, and Scott Hahn. Efficient Operating System Scheduling for Performance-Asymmetric Multi-Core Architectures, SC07 November 10-16, 2007, Reno, Nevada, USA. [21] Chee Siang Wong, Ian Tan, Rosalind Deena, and Fun Wey. Towards Achieving Fairness in the Linux Scheduler, ACM SIGOPS Operating Systems Review, Volume 42, Issue 5, July 2008, Pages 34-43. [22] AVISHAY TRAEGER and EREZ ZADOK, NIKOLAI JOUKOV and CHARLES P. WRIGHT. A Nine Year Study of File System and Storage Benchmarking, ACM Transactions on Storage, Vol. 4, No. 2, Article 5, May 2008. [23] Vijay Sundaram, Abhishek Chandra and Pawan Goyal. Application Performance in the QLinux Multimedia Operating System, ACM Multimedia 2000. [24] M. Correa, A. Zorzo and R. Scheer. Operating System Multilevel Load Balancing, SAC 06, April 23-27, 2006. [25] Wanghong Yuan, Klara Nahrstedt. Energy-Efficient Soft Real-Time CPU Scheduling for Mobile Multimedia Systems, SOSP ’03, October 19-22, 2003. [26] Wanghong Yuan, Klara Nahrstedt. Energy-Efficient CPU Scheduling for Multimedia Applications, ACM Transactions on Computer Systems, Vol. 24, No. 3, August 2006, Pages 292-331. 21
[27] JFFS2, http://en.wikipedia.org/wiki/JFFS2, November 2008 [28] Bryan Veal, Annie Foong. Performance scalability of a multi-core web server, Proceedings of the 3rd ACM/IEEE Symposium on Architecture for networking and communications systems, 2007, Pages 57-66. [29] YAFFS, http://en.wikipedia.org/wiki/YAFFS, November 2008 [30] SQLite, http://en.wikipedia.org/wiki/SQLite, November 2008 [31] Mark Russinovich. Inside the Windows Vista Kernel: http://technet.microsoft.com/en-us/magazine/cc162494.aspx Technet, February 2007.
Part 1, Microsoft
[32] Adrian Kingsley-Hughes. Microsoft responds to Vista network performance issue, http://blogs.zdnet.com/hardware/?p=724, November 2008 [33] Quality of Service, http://en.wikipedia.org/wiki/QoS, November 2008 [34] Well-Known Users of SQLite, http://www.sqlite.org/famous.html, November 2008 [35] Apache Lucene - Features, http://lucene.apache.org/java/docs/features.html, November 2008
22
¨ Lemminkaisenkatu 14 A, 20520 Turku, Finland | www.tucs.fi
University of Turku • Department of Information Technology • Department of Mathematics
˚ Abo Akademi University • Department of Computer Science • Institute for Advanced Management Systems Research
Turku School of Economics and Business Administration • Institute of Information Systems Sciences
ISBN 978-952-12-2229-0 ISSN 1239-1891
