WO2013021441A1 - データ処理システム、およびデータ処理方法 - Google Patents

データ処理システム、およびデータ処理方法 Download PDF

Info

Publication number
WO2013021441A1
WO2013021441A1 PCT/JP2011/067990 JP2011067990W WO2013021441A1 WO 2013021441 A1 WO2013021441 A1 WO 2013021441A1 JP 2011067990 W JP2011067990 W JP 2011067990W WO 2013021441 A1 WO2013021441 A1 WO 2013021441A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
thread
data processing
peripheral
cpu
Prior art date
Application number
PCT/JP2011/067990
Other languages
English (en)
French (fr)
Inventor
浩一郎 山下
宏真 山内
鈴木　貴久
康志 栗原
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2011/067990 priority Critical patent/WO2013021441A1/ja
Priority to JP2013527764A priority patent/JP5776776B2/ja
Publication of WO2013021441A1 publication Critical patent/WO2013021441A1/ja
Priority to US14/172,005 priority patent/US9405470B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present invention relates to a data processing system and a data processing method for managing a memory.
  • RAM Random Access Memory
  • GRAM Graphics RAM
  • DSP DSP
  • GPU Graphics Processing Unit
  • buffer memory used by Digital Signal Processor, VRAM (Video RAM) of LCD (Liquid Crystal Display) controller, and the like.
  • a technique is disclosed in which a thread is generated for memory access from application software (hereinafter referred to as “app”), and the corresponding thread manages memory access.
  • app application software
  • the thread is a basic unit for managing processing performed by the CPU.
  • An object of the present invention is to provide a data processing system and a data processing method capable of managing a plurality of memories without causing a conflict due to a plurality of accesses in order to solve the above-described problems caused by the prior art.
  • a plurality of data processing devices a peripheral device, a plurality of data processing devices and a memory shared by the peripheral device, and a peripheral device And a memory based on thread information based on thread information read from a heap area that stores thread information executed in a plurality of data processing devices or peripheral devices in a sequence.
  • a data processing system and a data processing method including a memory management unit for allocating an area are proposed.
  • FIG. 1 is an explanatory diagram showing an operation example of the multi-core processor system.
  • FIG. 2 is a block diagram illustrating a hardware example of the multi-core processor system.
  • FIG. 3 is a block diagram illustrating a software example of the multi-core processor system.
  • FIG. 4 is a block diagram illustrating an example of functions of the multi-core processor system.
  • FIG. 5 is an explanatory diagram showing an example of the contents stored in the management request dispatch table.
  • FIG. 6 is an explanatory diagram of an example of the contents stored in the memory usage table.
  • FIG. 7 is an explanatory diagram showing an example of a thread operation history table.
  • FIG. 8 is an explanatory diagram showing an example of a thread allocation method when the load is not in an equilibrium state.
  • FIG. 1 is an explanatory diagram showing an operation example of the multi-core processor system.
  • FIG. 2 is a block diagram illustrating a hardware example of the multi-core processor system.
  • FIG. 3 is a block diagram illustrating
  • FIG. 9 is an explanatory diagram illustrating an example of a thread allocation method when the load is in a balanced state.
  • FIG. 10 is an explanatory diagram (part 1) illustrating an example of a memory securing method.
  • FIG. 11 is an explanatory diagram (part 2) of an example of a memory securing method.
  • FIG. 12 is a flowchart illustrating an example of a memory management request processing procedure.
  • FIG. 13 is a flowchart illustrating an example of a processing procedure of the memory management thread.
  • FIG. 14 is a flowchart illustrating an example of an assignment destination CPU selection process for an assignment target thread by the scheduler.
  • FIG. 15 is a flowchart illustrating an example of a memory reservation destination selection process.
  • FIG. 16 is an explanatory diagram showing an application example of a system using a computer according to the present embodiment.
  • a multi-core processor is a processor having a plurality of cores. If a plurality of cores are mounted, a single processor having a plurality of cores may be used, or a processor group in which single core processors are arranged in parallel may be used. In the present embodiment, in order to simplify the explanation, a processor group in which single-core processors are arranged in parallel will be described as an example.
  • FIG. 1 is an explanatory diagram showing an operation example of the multi-core processor system.
  • the multi-core processor system 100 includes a CPU # 0, a CPU # 1, a GPU 101, a GPU memory 102, and a main memory 103.
  • the symbol accompanied by the suffix “#n” indicates that the symbol corresponds to the nth CPU.
  • CPU # 0 and CPU # 1 are connected by a local bus 112, and the GPU 101 and GPU memory 102 are connected by a local bus 113.
  • the local bus 112, the local bus 113, and the main memory 103 are connected by a bus 111.
  • the main memory 103 is a memory having a high access speed
  • the GPU memory 102 is a memory having a low access speed.
  • a device other than the CPU is referred to as a peripheral device.
  • a memory provided corresponding to the peripheral device is referred to as a peripheral memory.
  • the GPU memory 102 is a peripheral memory.
  • CPU # 0 executes the high priority thread 0
  • CPU # 1 executes the low priority thread 1 and the memory management thread 122.
  • CPU # 0 and CPU # 1 execute a memory securing request such as a malloc () function by thread 0 and thread 1
  • dummy device driver 121 # 0 and dummy device driver 121 # 1 are executed.
  • the dummy device driver 121 is an API (Application Programming Interface) having the same interface as a normal device driver in each peripheral device.
  • the thread can perform the same operation on the dummy device driver 121 as the normal device driver.
  • the dummy device driver 121 stores the memory reservation request with the thread information added to the management request dispatch table 123 stored in the main memory 103.
  • the thread information is information including a thread name, thread priority information, and the like.
  • the memory management thread 122 sequentially reads out the memory securing requests from the management request dispatch table 123, and secures the area of the main memory 103 or the GPU memory 102 based on the thread information of the memory securing request.
  • the memory management thread 122 first secures the thread 0 area 131 in the main memory 103 and then secures the thread 1 area 132 in the GPU memory 102.
  • the multi-core processor system 100 stores memory reservation requests from threads being executed by a plurality of CPUs in the management request dispatch table 123, sequentially reads the reservation requests, and assigns them to the main memory 103 and peripheral device memory.
  • the multi-core processor system 100 can secure a memory without causing contention due to multiple accesses.
  • the multi-core processor system 100 that performs the operation shown in FIG. 1 will be described with reference to FIGS.
  • FIG. 2 is a block diagram illustrating a hardware example of a multi-core processor system.
  • a multi-core processor system 100 assuming a mobile terminal such as a mobile phone includes a CPU # 0, a CPU # 1, a GPU 101, a GPU memory 102, a main memory 103, a DSP 201, a DSP memory 202, including.
  • the DSP 201 and the DSP memory 202 are connected by a local bus 203.
  • the multi-core processor system 100 includes a ROM (Read-Only Memory) 204, a RAM 205, a flash ROM 206, a flash ROM controller 207, and a flash ROM 208.
  • ROM Read-Only Memory
  • the multi-core processor system 100 includes a display 209, an I / F (Interface) 210, and a keyboard 211 as input / output devices for a user and other devices. Each unit is connected by a bus 111.
  • the main memory 103 shown in FIG. 1 may be the RAM 205 or a part of the RAM 205.
  • the main memory 103 is a memory that can be shared and accessed from the CPU # 0, CPU # 1, GPU 101, DSP 201, and the like.
  • CPU # 0 and CPU # 1 control the entire multi-core processor system 100.
  • CPU # 0 and CPU # 1 indicate all CPUs in which single-core processors are connected in parallel.
  • the multi-core processor system 100 may include three or more CPUs.
  • Each of the CPUs # 0 to #n has a dedicated cache memory.
  • the ROM 204 stores a program such as a boot program.
  • the RAM 205 is used as a work area for CPU # 0 and CPU # 1.
  • the flash ROM 206 is a flash ROM having a high reading speed, and is, for example, a NOR type flash memory.
  • the flash ROM 206 stores system software such as an OS (Operating System), applications, and the like. For example, when the OS is updated, the multi-core processor system 100 receives the new OS by the I / F 210 and updates the old OS stored in the flash ROM 206 to the received new OS.
  • OS Operating System
  • the flash ROM controller 207 controls reading / writing of data with respect to the flash ROM 208 in accordance with the control of the CPU # 0 and CPU # 1.
  • the flash ROM 208 is a flash ROM mainly for storing and transporting data, for example, a NAND flash memory.
  • the flash ROM 208 stores data written under the control of the flash ROM controller 207.
  • data image data and video data acquired by the user using the multi-core processor system 100 through the I / F 210, a program for executing the data processing method according to the present embodiment, and the like may be stored. Good.
  • the flash ROM 208 for example, a memory card, an SD card, or the like can be adopted.
  • the display 209 displays data such as a document, an image, and function information as well as a cursor, an icon, or a tool box.
  • a TFT liquid crystal display can be adopted as the display 209.
  • the I / F 210 is connected to a network 212 such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet through a communication line, and is connected to another device via the network 212.
  • the I / F 210 controls an internal interface with the network 212 and controls input / output of data from an external device.
  • a modem or a LAN adapter may be employed as the I / F 210.
  • the keyboard 211 has keys for inputting numbers, various instructions, etc., and inputs data.
  • the keyboard 211 may be a touch panel type input pad or a numeric keypad.
  • the multi-core processor system 100 becomes a shared memory architecture when only the CPU group is viewed, but becomes a distributed memory architecture having a plurality of masters for the memory such as the GPU 101 and the DSP 201. Further, the main memory 103, the GPU memory 102, and the DSP memory 202 are handled as a shared space that can be accessed from each master, and have a complicated nested hierarchy.
  • FIG. 3 is a block diagram showing a software example of the multi-core processor system.
  • the multi-core processor system 100 executes a kernel 301, a scheduler 302, a memory management thread 122, a DSP dummy device driver 303, and a GPU dummy device driver 304 as software provided by the OS.
  • the memory management thread 122 includes a main memory management unit 311, a DSP memory management unit 312, and a GPU memory management unit 313.
  • the kernel 301, the DSP dummy device driver 303, and the GPU dummy device driver 304 are executed by the CPU # 0 and the CPU # 1, respectively.
  • the CPU # 0 executes a kernel 301 # 0, a DSP dummy device driver 303 # 0, and a GPU dummy device driver 304 # 0.
  • the CPU # 1 executes the kernel 301 # 1, the DSP dummy device driver 303 # 1, and the GPU dummy device driver 304 # 1.
  • the scheduler 302 may be operated by either the CPU # 0 or the CPU # 1, but is executed by the CPU # 0 serving as the master CPU in the multi-core processor system 100 in the present embodiment.
  • the memory management thread 122 is executed by either CPU # 0 or CPU # 1.
  • Kernel 301 has a core function of the OS. For example, the kernel 301 expands the program code in the main memory 103 when the application is activated.
  • the scheduler 302 has a function of assigning a thread to be executed in the multi-core processor system 100 to each CPU and selecting a thread to be executed next. For example, the scheduler 302 assigns thread 0 to CPU # 0 and assigns thread 1 to CPU # 1.
  • the DSP dummy device driver 303 and the GPU dummy device driver 304 are dummy device drivers 121 for the device drivers of the GPU 101 and the DSP 201, respectively.
  • the main memory management unit 311, the DSP memory management unit 312, and the GPU memory management unit 313 have a function of managing the main memory 103, the DSP memory 202, and the GPU memory 102, respectively.
  • the main memory management unit 311, the DSP memory management unit 312, and the GPU memory management unit 313 store a physical address of each memory and a physical address range that can be secured.
  • the main memory management unit 311 updates the usage status in response to a securing request and a releasing request to the main memory 103.
  • the DSP memory management unit 312 and the GPU memory management unit 313 also update the usage statuses of the DSP memory 202 and the GPU memory 102, respectively.
  • FIG. 4 is a block diagram illustrating an example of functions of the multi-core processor system.
  • the multi-core processor system 100 includes a storage unit 401, a determination unit 402, an allocation unit 403, an upper memory management unit 404, a memory management unit 405, an update unit 411, a reading unit 412, and a selection unit 413.
  • Unit 414 and notification unit 415 The functions (storage unit 401 to notification unit 415) serving as the control unit are realized by the CPU # 0 and CPU # 1 executing the program stored in the storage device.
  • the storage device is, for example, the ROM 204, the RAM 205, the flash ROM 206, the flash ROM 208, etc. shown in FIG.
  • the storage unit 401 is a function of the dummy device driver 121.
  • the determination unit 402 and the allocation unit 403 are functions of the scheduler 302
  • the upper memory management unit 404 is a function of the memory management thread 122
  • the memory management unit 405 is a function of the main memory management unit 311 to the GPU memory management unit 313. It is.
  • the update unit 411, the reading unit 412, and the selection unit 413 are included in the upper memory management unit 404
  • the securing unit 414 and the notification unit 415 are included in the memory management unit 405.
  • the determination unit 402 and the allocation unit 403 are functions of the CPU # 0, and the upper memory management unit 404 is illustrated as the function of the CPU # 1, but the determination unit 402 and the allocation unit 403 are the CPU # 0. 1 and the upper memory management unit 404 may be the function of the CPU # 0.
  • the multi-core processor system 100 can access the management request dispatch table 123, the memory use table 421, and the thread operation history table 422.
  • the management request dispatch table 123 exists in a heap area, which is a memory that can be dynamically secured, and stores thread information and memory management requests executed by the CPU # 0, CPU # 1, GPU 101, and DSP 201. Details of the management request dispatch table 123 will be described later with reference to FIG.
  • the memory usage table 421 stores the availability of the main memory 103 and peripheral memory. Details of the memory usage table 421 will be described later with reference to FIG.
  • the thread operation history table 422 stores information on which CPU each thread has operated on. Details of the thread operation history table 422 will be described later with reference to FIG.
  • the storage unit 401 has a function of storing thread information executed in a plurality of data processing devices or peripheral devices in a heap area in sequence.
  • the storage unit 401 stores thread information executed by the CPU # 0, CPU # 1, GPU 101, and DSP 201 in the management request dispatch table 123.
  • Storing thread information in a sequence means storing thread information in order.
  • the determination unit 402 has a function of determining whether or not loads of a plurality of data processing devices are in an equilibrium state. For example, the determination unit 402 determines whether or not the loads on the CPU # 0 and the CPU # 1 are in an equilibrium state. As an example of the determination method, for example, the determination unit 402 uses the load amount determination function of the OS to calculate the time that the thread occupies the CPU for each CPU, and determines the load amount of each CPU. Judge based. When the load amount of each CPU is equal, or when the load amount of each CPU can be approximated based on the threshold value, the determination unit 402 determines that it is in an equilibrium state. Judge not in state. Note that the determination result is stored in a storage area such as the RAM 205 and the flash ROM 206.
  • the allocation unit 403 has a function of allocating the execution of the upper memory management unit 404 and the memory management unit 405 to the data processing device with the smallest load among the plurality of data processing devices when the determination unit 402 is not in a load balanced state. . For example, when the CPU # 0 and the CPU # 1 are not in a load balanced state, the allocation unit 403 allocates the memory management thread 122 to a CPU with a small load.
  • the allocation unit 403 may allocate the execution of the upper memory management unit 404 and the memory management unit 405 to a data processing device or a peripheral device allocated in the past when the determination unit 402 is in a load balanced state. For example, when the CPU # 0 and the CPU # 1 are in a load balanced state, the allocating unit 403 refers to the thread operation history table 422 and allocates the CPUs allocated in the past.
  • the upper memory management unit 404 has a function of managing the usage status of the main memory 103 and the peripheral memory. For example, the upper memory management unit 404 inquires of the memory management unit 405 about the memory usage status and receives a usage status notification from the memory management unit 405.
  • the memory management unit 405 has a function of managing the memory.
  • the memory management unit 405 exists for each memory such as the main memory 103, the GPU memory 102, and the DSP memory 202.
  • the memory management unit 405 performs logical-physical conversion on each memory to perform area allocation, re-allocation, release, read, write, and the like.
  • the update unit 411 has a function of updating the memory usage table 421 from the notified usage status. For example, the update unit 411 stores the usage status notified from the memory management unit 405 in the memory usage table 421.
  • the reading unit 412 has a function of reading thread information from the heap area. For example, the reading unit 412 reads thread information from the management request dispatch table 123. Note that the read result is stored in a storage area such as the RAM 205 and the flash ROM 206.
  • the selection unit 413 has a function of selecting, from the memory or the peripheral memory, a reservation destination for a memory reservation request from a thread based on the thread information based on the thread information read from the heap area.
  • the selection unit 413 may select a reservation destination for a memory reservation request from a thread based on priority information based on thread information. For example, if the priority is high priority, the selection unit 413 selects the high-speed main memory 103 as a reservation destination. If the priority is low, the selection unit 413 selects the DSP memory 202 that is slower than the main memory 103 as the reservation destination.
  • the selection unit 413 may select the peripheral memory as a reservation destination for the memory reservation request.
  • the selection result is stored in a storage area such as the RAM 205 and the flash ROM 206.
  • the securing unit 414 has a function of securing an area in the secured memory selected by the selection unit 413. For example, the securing unit 414 secures an area in the main memory 103 when the main memory 103 is selected as the securing destination. The reserved area is notified to the requesting thread.
  • the notification unit 415 has a function of notifying the upper memory management unit 404 of the memory usage status.
  • the notification unit 415 serving as a function of the main memory management unit 311 notifies the upper memory management unit 404 of the usage status of the main memory 103.
  • the notification unit 415 serving as a function of the DSP memory management unit 312 notifies the upper memory management unit 404 of the usage status of the DSP memory 202.
  • the notification unit 415 serving as a function of the GPU memory management unit 313 notifies the upper memory management unit 404 of the usage status of the GPU memory 102.
  • FIG. 5 is an explanatory diagram showing an example of the contents stored in the management request dispatch table.
  • the contents stored in the management request dispatch table 123 will be described.
  • the management request dispatch table 123 exists for each memory.
  • the management request dispatch table 123 stores management requests for three memories: the main memory 103, the GPU memory 102, and the DSP memory 202.
  • the management request dispatch table 123_M stores management requests for the main memory 103
  • the management request dispatch table 123_G stores management requests for the GPU memory 102
  • the management request dispatch table 123_D stores management requests for the DSP memory 202.
  • the management request dispatch table 123_M will be described, but the management request dispatch table 123_G and the management request dispatch table 123_D have the same storage contents, and thus the description thereof is omitted.
  • the management request dispatch table 123_M shown in FIG. 5 stores records 123_M-1 to 123_M-n. n is a natural number.
  • the management request dispatch table 123_M includes two fields: a request source thread ID and a request memory size. In the request source thread ID field, the thread that made the memory securing request is stored.
  • the requested memory size field stores the number of bytes for which a memory securing request has been made. For example, the record 123_M-1 stores a memory allocation request for threads 0 to 32 [bytes].
  • the management request dispatch table 123_M exists in a heap area that is a dynamically securable memory, and has a structure in which each record is connected by a pointer. Specifically, the record 123_M-1 has a pointer to the record 123_M-2. Similarly, the record 123_M-2 has a pointer to the record 123_M-3, and the record 123_M-3 has a pointer to the record 123_M-4. The record 123_M-n has a pointer to the record 123_M-1.
  • the management request dispatch table 123 shown in FIG. 5 illustrates a memory allocation request as a memory management request, but includes a memory re-allocation request and a memory release request as other memory management requests. Also good. Furthermore, the memory management request may include a read / write request to the memory.
  • the fields held by one record of the management request dispatch table 123 are a request source thread ID field and an argument of each request.
  • the arguments of each request are, for example, an allocated address and a requested memory size, which are arguments of the realloc () function if the request is to reallocate the memory, and the free () function if the request is to release the memory. This is the address to be released.
  • FIG. 6 is an explanatory diagram showing an example of the contents stored in the memory usage table.
  • the memory usage table 421 is a table that stores the free capacity for each memory type. Records 421-1 to 421-3 are registered in the memory usage table 421 shown in FIG. Records 421-1 to 421-3 are registered in the order of access speeds from threads executed by CPU # 0 and CPU # 1. For example, the records 421-1 to 421-3 shown in FIG. 6 are registered in descending order, but may be registered in ascending order.
  • the memory use table 421 includes two fields: memory type and free capacity.
  • memory type field identification information for identifying each memory is stored.
  • the free capacity field stores the free capacity of the memory.
  • the record 421-1 indicates that the free capacity of the main memory 103 having the fastest access speed in the memory group is 50 [M bytes].
  • the record 421-2 indicates that the free capacity of the GPU memory 102 having the next highest access speed is 10 [M bytes].
  • the record 421-3 indicates that the free capacity of the DSP memory 202 having a slow access speed is 20 [M bytes].
  • FIG. 7 is an explanatory diagram showing an example of a thread operation history table.
  • the thread operation history table 422 is a table that stores a history of past thread operations.
  • the thread operation history table 422 shown in FIG. 7 stores records 422-1 to 422-5.
  • the thread operation history table 422 includes two fields: a thread ID and an operation CPUID.
  • the thread ID field stores the ID of the operated thread.
  • the operation CPUID field stores the CPUID in which the thread has operated.
  • the thread operation history table 422 shown in FIG. 7 indicates that the memory management thread 122 and the thread 1 are operating twice on the CPU # 1, and the thread 0 is operating once on the CPU # 0. .
  • the multi-core processor system 100 uses the functions shown in FIG. 4 and the stored contents shown in FIGS. 5 to 7 to allocate threads and secure memory. 8 and 9 show an example of a thread allocation method, and FIGS. 10 and 11 show an example of a memory securing method.
  • FIG. 8 is an explanatory diagram showing an example of a thread allocation method when the load is not in a balanced state.
  • CPU # 0 executes thread 0
  • CPU # 1 executes thread 1 and thread 2.
  • the scheduler 302 allocates the memory management thread 122 to the CPU with the smallest load because the load of each CPU is not in an equilibrium state in the state of the multi-core processor system 100 in FIG. .
  • FIG. 9 is an explanatory diagram showing an example of a thread allocation method when the load is in a balanced state.
  • CPU # 0 executes thread 0 and thread 2
  • CPU # 1 executes thread 1 and thread 3.
  • the scheduler 302 assigns the memory management thread 122 to the CPU to which the memory management thread 122 has been allocated in the past. assign.
  • the scheduler 302 allocates the memory management thread 122 to the CPU # 1 because the memory management thread 122 has been operated twice by the CPU # 1 in the past. . Note that, based on the past operation history, each thread is often assigned to the same CPU.
  • the thread 0 shown in FIGS. 10 and 11 assumes a menu program, uses the GPU 101, and has a medium priority.
  • the thread 1 assumes a multimedia program, uses the DSP 201, and has a high priority.
  • the thread 3 is assumed to be a communication program and has a low priority.
  • FIG. 10 is an explanatory diagram (part 1) illustrating an example of a memory securing method.
  • the CPU # 0 executing the thread 0 accesses the thread 0 area 1001 allocated in the main memory 103 by the memory management thread 122 and performs processing.
  • the reason why the thread 0 area 1001 is allocated in the main memory 103 is, for example, when the GPU memory 102 and the DSP memory 202 are not empty when the allocation is performed.
  • the memory management thread 122 issues a memory reservation request from a thread having a low priority.
  • the memory management thread 122 makes a memory reservation request for the thread 1 after making a memory reservation request for the thread 0.
  • the memory management thread 122 executes the GPU memory management unit 313 to secure the thread 0 area 1002 in the GPU memory 102 having a low access speed.
  • the memory management thread 122 executes the main memory management unit 311 to secure the thread 1 area 1003 in the main memory 103 having a high access speed.
  • FIG. 11 is an explanatory diagram (part 2) illustrating an example of a memory securing method.
  • thread 0 and thread 2 are assigned to CPU # 0
  • thread 1 is assigned to CPU # 1.
  • the memory management thread 122 first makes a memory securing request for the thread 2, then makes a memory securing request for the thread 0, and finally makes a memory securing request for the thread 1.
  • the memory management thread 122 executes the DSP memory management unit 312 to secure the thread 2 area 1101 in the DSP memory 202 having a low access speed.
  • the memory management thread 122 executes the GPU memory management unit 313 to reserve the thread 0 area 1102 in the GPU memory 102 having a medium access speed.
  • the memory management thread 122 executes the main memory management unit 311 to secure the thread 1 area 1103 in the main memory 103 having a high access speed.
  • the multi-core processor system 100 may release the thread 0 area 1102 in some cases.
  • a thread using the GPU initializes the GPU 101 and the GPU memory 102.
  • FIG. 12 is a flowchart showing an example of a memory management request processing procedure.
  • the memory management request process is executed by the dummy device driver 121 of each CPU.
  • the memory management request process is executed by the dummy device driver 121 # 0 of the CPU # 0.
  • CPU # 0 accepts an access request from the user thread to the peripheral device (step S1201).
  • CPU # 0 stores the memory management request in the management request dispatch table 123 (step S1202).
  • CPU # 0 notifies the memory management thread 122 of the execution request (step S1203), and ends the memory management request process.
  • FIG. 13 is a flowchart showing an example of the processing procedure of the memory management thread.
  • the memory management thread 122 is executed by either the CPU # 0 or the CPU # 1 by an assignment destination CPU selection process of the scheduler 302 shown in FIG. In FIG. 13, it is assumed that the memory management thread 122 is executed by the CPU # 0.
  • CPU # 0 determines whether or not the memory management thread 122 is periodically executed (step S1301). When regularly executed (step S1301: Yes), the CPU # 0 inquires the memory management unit of each device about the usage status and the available status (step S1302). After accepting the inquiry as the memory management unit of each device, the CPU # 0 notifies the memory management thread 122 of the usage status and the availability status (step S1303). The CPU # 0 that has received the notification updates the memory use table 421 from the notification result (step S1304), and ends the processing of the memory management thread 122.
  • the CPU # 0 reads a record in the management request dispatch table 123 (step S1305).
  • the management request dispatch table 123 may store a plurality of records. When there are a plurality of memory allocation requests, the CPU # 0 may sequentially read the memory allocation requests with the lower priority of the corresponding thread.
  • the CPU # 0 can store the memory of the low thread in the flash ROM 206 and the flash ROM 208. Swap out. In this way, by relocating the reserved area, the multi-core processor system 100 can prevent the storage area from being fragmented. If memory is allocated in order from the thread with the higher priority, the area reserved for the thread with the higher priority cannot be moved from the thread with the lower priority, and the storage area may be fragmented. There is.
  • CPU # 0 determines whether there is a memory reservation request in the read record (step S1306). When there is a memory reservation request (step S1306: Yes), the CPU # 0 executes a memory reservation destination selection process (step S1307).
  • the memory allocation destination selection process will be described later with reference to FIG.
  • the CPU # 0 executes the memory management unit of the target device (step S1308).
  • the memory management unit of the target device for example, if the memory management request is a memory reservation request, the CPU # 0 secures the memory for the target memory.
  • the target memory is a memory selected in step S1504 or step S1505 described later. For example, when the main memory 103 is selected as the reservation destination, the main memory 103 becomes the target memory.
  • the processing completion table is a table that stores a memory management request that has been processed together with a return value.
  • the dummy device driver 121 refers to the return value for the memory management request in the processing completion table and makes a response to the memory management request to the calling application.
  • FIG. 14 is a flowchart showing an example of an assignment destination CPU selection process of the assignment target thread by the scheduler.
  • the scheduler 302 is assumed to be executed by the CPU # 0 in this embodiment.
  • threads that can be assigned threads are a user thread, a memory management thread 122, and the like.
  • CPU # 0 determines whether or not the load balanced state is balanced (step S1401). When the load is balanced (step S1401: Yes), the CPU # 0 allocates the allocation target thread to the CPU in which the allocation target thread has operated in the past (step S1402). When the load is not balanced (step S1401: No), the CPU # 0 allocates an allocation target thread to the low-load CPU (step S1402). After the end of steps S1402 and S1403, CPU # 0 ends the thread assignment destination CPU selection process.
  • FIG. 15 is a flowchart illustrating an example of a memory reservation destination selection process.
  • the memory reservation destination selection process is executed by the same CPU as the memory management thread 122.
  • CPU # 0 executes.
  • CPU # 0 determines whether the caller of memory management thread 122 is a user thread (step S1501).
  • step S1501 user thread
  • step S1502 low priority, medium priority
  • step S1503 the CPU # 0 refers to the thread operation history table 422 to determine whether or not there is a free space in the peripheral memory.
  • step S1503: No When there is no free space (step S1503: No), or when the priority is high (step S1502: high priority), the CPU # 0 selects the main memory 103 as the securing destination from the main memory 103 and the peripheral memory. (Step S1504). After selecting the reservation destination, the CPU # 0 ends the memory reservation destination selection process. When there is an empty space (step S1503: Yes), or when the caller is a device driver (step S1501: device driver), the CPU # 0 selects the peripheral memory as the allocation destination from the main memory 103 and the peripheral memory. (Step S1505). After selecting the reservation destination, the CPU # 0 ends the memory reservation destination selection process.
  • FIG. 16 is an explanatory diagram showing an application example of a system using a computer according to the present embodiment.
  • a network NW is a network in which a server 1601, a server 1602, and clients 1631 to 1634 can communicate, and includes, for example, a LAN, a WAN, the Internet, a mobile phone network, and the like.
  • the server 1602 is a management server of a server group (server 1621 to server 1625) having the cloud 1620.
  • the client 1631 is a notebook PC (Personal Computer).
  • the client 1632 is a desktop PC, and the client 1633 is a mobile phone. As a mobile phone, the client 1633 may be a smartphone or a PHS (Personal Handyphone System).
  • the client 1634 is a tablet terminal.
  • the server 1601, the server 1602, the server 1621 to the server 1625, and the client 1631 to the client 1634 execute the data processing system according to the present embodiment, for example, as the data processing device described in the embodiment.
  • the server 1621 has the fastest memory and the servers 1622 to 1625 have low-speed memory.
  • the data processing system regards the memory of the server 1621 as the main memory 103 in the present embodiment, and regards the memories of the servers 1622 to 1625 as the memories of the peripheral devices, thereby enabling the data processing method according to the present embodiment. Can be executed.
  • the memory management requests from the threads being executed by the plurality of data processing devices are stored in the shared memory, the management requests are sequentially read out, the main memory and the peripheral Reserve device memory.
  • the memory can be managed without causing contention due to multiple accesses from the data processing system and the plurality of data processing devices.
  • the memory management request is not called at the same timing, and access contention does not occur.
  • the data processing system may assign a memory management thread for performing memory management to the data processing device having the smallest load among the data processing devices.
  • the data processing system can load balance memory management processing without causing access contention.
  • an exclusive control process has to be performed, resulting in an increase in overhead.
  • the load is biased.
  • the data processing system may assign the memory management thread to the data processing device to which the corresponding thread has been assigned in the past.
  • the data processing device to which the memory management thread is assigned can perform processing at high speed using the cache of the thread remaining in the cache memory.
  • the memory management thread has a memory management routine as a program and an allocate table for a memory area secured as data. If the memory management routine remains in the instruction cache, the memory management thread can execute processing immediately. Further, when the allocate table remains in the data cache, the memory management thread can immediately execute the table management.
  • the data processing system may reserve an area from either the main memory or the peripheral memory based on the priority information of the thread that has requested the memory securing. Also, the data processing system may reserve a memory area with a high memory access speed when the thread that has requested the memory reservation has a high priority. As a result, the data processing system can perform high-speed processing using a memory capable of high-speed access for threads that require high-speed processing.
  • the data processing system may reserve the area of the peripheral memory if the thread that has requested the memory reservation has medium priority or low priority, and the peripheral memory is free.
  • the peripheral memory consumes less power because it is slower than the main memory. Therefore, when it is not necessary to perform high-speed processing, the data processing system can reduce power consumption and improve power efficiency by securing a peripheral memory with low power consumption.
  • the data processing system may reserve the peripheral memory area if the thread that has requested the memory reservation is a thread that manages the peripheral device. Thereby, the data processing system can execute a thread corresponding to the peripheral device even if the thread uses the peripheral device.
  • the data processing system may collect the usage status of the memory and peripheral memory. As a result, the data processing system can check the free capacity of each peripheral memory, so that the memory is free and can be secured from a low-speed memory.
  • the data processing method described in the present embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation.
  • a program for executing this data processing method is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer.
  • the program for executing this data processing method may be distributed via a network such as the Internet.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Multi Processors (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

　複数アクセスによる競合を発生させずに複数のメモリを管理する。マルチコアプロセッサシステム（１００）は、ＣＰＵ（＃０）で実行中のスレッド（０）、ＣＰＵ（＃１）で実行中のスレッド（１）からのメモリ確保要求を管理要求ディスパッチテーブル（１２３）に格納する。メモリ管理スレッド（１２２）は、管理要求ディスパッチテーブル（１２３）から確保要求を順に読み出し、初めにスレッド０用領域（１３１）をメインメモリ（１０３）内に確保し、次にスレッド１用領域（１３２）をＧＰＵメモリ（１０２）内に確保する。

Description

データ処理システム、およびデータ処理方法
　本発明は、メモリを管理するデータ処理システム、およびデータ処理方法に関する。
　従来から、携帯電話等の携帯端末のメモリアーキテクチャには、様々なメモリが搭載されている。具体的なメモリの種類としては、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）が主にアクセスするメインメモリとなるＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）の他に、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）が用いるＧＲＡＭ（Ｇｒａｐｈｉｃｓ　ＲＡＭ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）が用いるバッファ用メモリ、ＬＣＤ（Ｌｉｑｕｉｄ　Ｃｒｙｓｔａｌ　Ｄｉｓｐｌａｙ）コントローラのＶＲＡＭ（Ｖｉｄｅｏ　ＲＡＭ）などが存在する。
　このような様々なメモリのアクセス方法に関して、たとえば、アプリケーションソフトウェア（以下、「アプリ」と称する）からのメモリアクセスに対してスレッドを生成し、該当のスレッドがメモリアクセスに関する管理を行う技術が開示されている（たとえば、下記特許文献１を参照。）。なお、スレッドとはＣＰＵで行う処理を管理するための基本単位である。
特開２００８－１０８０８９号公報
　しかしながら、上述した従来技術において、メモリアクセスの管理をするスレッドを、任意のＣＰＵで実行できるようにすると、同時アクセスによる競合を避けるため、排他制御処理を追加せねばならず、オーバーヘッドが増加するという問題があった。
　本発明は、上述した従来技術による問題点を解消するため、複数アクセスによる競合を発生させずに複数のメモリを管理できるデータ処理システム、およびデータ処理方法を提供することを目的とする。
　上述した課題を解決し、目的を達成するため、本発明の一側面によれば、複数のデータ処理装置と、周辺装置と、複数のデータ処理装置および周辺装置に共有されるメモリと、周辺装置に対応して設けられる周辺メモリと、複数のデータ処理装置または周辺装置で実行されるスレッド情報をシーケンスに格納するヒープ領域から読み出されるスレッド情報に基づいてスレッド情報に基づくスレッドにメモリまたは周辺メモリの領域を割り当てるメモリ管理ユニットとを含むデータ処理システム、およびデータ処理方法が提案される。
　本発明の一側面によれば、複数アクセスによる競合を発生させずに複数のメモリを管理できるという効果を奏する。
図１は、マルチコアプロセッサシステムの動作例を示す説明図である。 図２は、マルチコアプロセッサシステムのハードウェア例を示すブロック図である。 図３は、マルチコアプロセッサシステムのソフトウェア例を示すブロック図である。 図４は、マルチコアプロセッサシステムの機能例を示すブロック図である。 図５は、管理要求ディスパッチテーブルの記憶内容の一例を示す説明図である。 図６は、メモリ使用テーブルの記憶内容の一例を示す説明図である。 図７は、スレッド動作履歴テーブルの一例を示す説明図である。 図８は、負荷が均衡状態でない場合のスレッド割当方法の一例を示す説明図である。 図９は、負荷が均衡状態である場合のスレッド割当方法の一例を示す説明図である。 図１０は、メモリの確保方法の一例を示す説明図（その１）である。 図１１は、メモリの確保方法の一例を示す説明図（その２）である。 図１２は、メモリ管理要求処理手順の一例を示すフローチャートである。 図１３は、メモリ管理スレッドの処理手順の一例を示すフローチャートである。 図１４は、スケジューラによる割当対象スレッドの割当先ＣＰＵ選択処理の一例を示すフローチャートである。 図１５は、メモリ確保先選択処理の一例を示すフローチャートである。 図１６は、本実施の形態にかかるコンピュータを用いたシステムの適用例を示す説明図である。
　以下に添付図面を参照して、開示のデータ処理システム、およびデータ処理方法の実施の形態を詳細に説明する。なお、本実施の形態にかかるデータ処理システムの例として、複数のＣＰＵを有するマルチコアプロセッサシステムにて説明を行う。マルチコアプロセッサとは、コアが複数搭載されたプロセッサである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、本実施の形態では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。
　図１は、マルチコアプロセッサシステムの動作例を示す説明図である。マルチコアプロセッサシステム１００は、ＣＰＵ＃０と、ＣＰＵ＃１と、ＧＰＵ１０１と、ＧＰＵメモリ１０２と、メインメモリ１０３と、を含む。以下、接尾記号“＃ｎ”が付随された記号は、ｎ番目のＣＰＵに対応する記号であることを示している。ＣＰＵ＃０とＣＰＵ＃１は、ローカルバス１１２で接続されており、ＧＰＵ１０１とＧＰＵメモリ１０２は、ローカルバス１１３で接続されている。ローカルバス１１２とローカルバス１１３とメインメモリ１０３は、バス１１１で接続されている。メインメモリ１０３は、アクセス速度が高速なメモリであり、ＧＰＵメモリ１０２は、アクセス速度が低速なメモリである。なお、ＣＰＵ以外の装置を周辺装置と称する。また、周辺装置に対応して設けられるメモリを周辺メモリと称する。図１の例では、ＧＰＵメモリ１０２が周辺メモリとなる。
　また、ＣＰＵ＃０は、高優先度のスレッド０を実行し、ＣＰＵ＃１は、低優先度のスレッド１とメモリ管理スレッド１２２を実行する。ＣＰＵ＃０、ＣＰＵ＃１は、スレッド０、スレッド１によるｍａｌｌｏｃ（）関数等といったメモリ確保要求を実行すると、ダミーデバイスドライバ１２１＃０、ダミーデバイスドライバ１２１＃１を実行する。
　ダミーデバイスドライバ１２１は、個々の周辺機器における通常のデバイスドライバと同一のインターフェースを有するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）である。スレッドは、ダミーデバイスドライバ１２１に対して通常のデバイスドライバと同一の操作を行うことができる。ダミーデバイスドライバ１２１は、メモリ確保要求を受け付けると、メインメモリ１０３に格納されている管理要求ディスパッチテーブル１２３にスレッド情報を付与したメモリ確保要求を格納する。スレッド情報とは、スレッドの名称、スレッドの優先度情報等が含まれた情報である。
　メモリ管理スレッド１２２は、管理要求ディスパッチテーブル１２３からメモリ確保要求を順に読み出し、メモリ確保要求のスレッド情報に基づいて、メインメモリ１０３、または、ＧＰＵメモリ１０２の領域を確保する。
　図１の例では、メモリ管理スレッド１２２は、初めにスレッド０用領域１３１をメインメモリ１０３内に確保し、次にスレッド１用領域１３２をＧＰＵメモリ１０２内に確保する。このように、マルチコアプロセッサシステム１００は、複数のＣＰＵで実行中のスレッドからのメモリ確保要求を管理要求ディスパッチテーブル１２３に格納し、確保要求を順に読み出し、メインメモリ１０３や周辺装置のメモリに割り当てる。これにより、マルチコアプロセッサシステム１００は、複数アクセスによる競合を発生させずにメモリ確保できる。図２～図１５にて、図１で示した動作を行うマルチコアプロセッサシステム１００について説明を行う。
　図２は、マルチコアプロセッサシステムのハードウェア例を示すブロック図である。図２において、携帯電話などの携帯端末を想定するマルチコアプロセッサシステム１００は、ＣＰＵ＃０と、ＣＰＵ＃１と、ＧＰＵ１０１と、ＧＰＵメモリ１０２と、メインメモリ１０３と、ＤＳＰ２０１と、ＤＳＰメモリ２０２と、を含む。ＤＳＰ２０１とＤＳＰメモリ２０２は、ローカルバス２０３で接続されている。また、マルチコアプロセッサシステム１００は、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ　Ｍｅｍｏｒｙ）２０４と、ＲＡＭ２０５と、フラッシュＲＯＭ２０６と、フラッシュＲＯＭコントローラ２０７と、フラッシュＲＯＭ２０８と、を含む。
　また、マルチコアプロセッサシステム１００は、ユーザやその他の機器との入出力装置として、ディスプレイ２０９と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２１０と、キーボード２１１と、を含む。また、各部はバス１１１によってそれぞれ接続されている。なお、図１に示したメインメモリ１０３は、ＲＡＭ２０５であってもよいし、ＲＡＭ２０５の一部であってもよい。また、メインメモリ１０３は、ＣＰＵ＃０、ＣＰＵ＃１、ＧＰＵ１０１、ＤＳＰ２０１、等から共有してアクセスできるメモリである。
　ここで、ＣＰＵ＃０、ＣＰＵ＃１は、マルチコアプロセッサシステム１００の全体の制御を司る。ＣＰＵ＃０、ＣＰＵ＃１は、シングルコアのプロセッサを並列して接続した全てのＣＰＵを指している。なお、マルチコアプロセッサシステム１００は、３つ以上のＣＰＵを含んでいてもよい。ＣＰＵ＃０～ＣＰＵ＃ｎは、それぞれ専用のキャッシュメモリを有している。
　ＲＯＭ２０４は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ２０５は、ＣＰＵ＃０、ＣＰＵ＃１のワークエリアとして使用される。フラッシュＲＯＭ２０６は、読出し速度が高速なフラッシュＲＯＭであり、たとえば、ＮＯＲ型フラッシュメモリである。フラッシュＲＯＭ２０６は、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）などのシステムソフトウェアやアプリなどを記憶している。たとえば、ＯＳを更新する場合、マルチコアプロセッサシステム１００は、Ｉ／Ｆ２１０によって新しいＯＳを受信し、フラッシュＲＯＭ２０６に格納されている古いＯＳを、受信した新しいＯＳに更新する。
　フラッシュＲＯＭコントローラ２０７は、ＣＰＵ＃０、ＣＰＵ＃１の制御にしたがってフラッシュＲＯＭ２０８に対するデータのリード／ライトを制御する。フラッシュＲＯＭ２０８は、データの保存、運搬を主に目的としたフラッシュＲＯＭであり、たとえば、ＮＡＮＤ型フラッシュメモリである。フラッシュＲＯＭ２０８は、フラッシュＲＯＭコントローラ２０７の制御で書き込まれたデータを記憶する。データの具体例としては、マルチコアプロセッサシステム１００を使用するユーザがＩ／Ｆ２１０を通して取得した画像データ、映像データなどや、また本実施の形態にかかるデータ処理方法を実行するプログラムなどを記憶してもよい。フラッシュＲＯＭ２０８は、たとえば、メモリカード、ＳＤカードなどを採用することができる。
　ディスプレイ２０９は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ２０９は、たとえば、ＴＦＴ液晶ディスプレイなどを採用することができる。
　Ｉ／Ｆ２１０は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク２１２に接続され、ネットワーク２１２を介して他の装置に接続される。そして、Ｉ／Ｆ２１０は、ネットワーク２１２と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２１０には、たとえばモデムやＬＡＮアダプタなどを採用することができる。
　キーボード２１１は、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボード２１１は、タッチパネル式の入力パッドやテンキーなどであってもよい。
　このように、マルチコアプロセッサシステム１００は、ＣＰＵ群だけを見ると、共有メモリアーキテクチャとなるが、ＧＰＵ１０１、ＤＳＰ２０１等といった、メモリに対して行うマスタを複数有する分散メモリアーキテクチャとなる。さらに、メインメモリ１０３、ＧＰＵメモリ１０２、ＤＳＰメモリ２０２は、各マスタから互いにアクセス可能な共有空間として扱われており、複雑な入れ子型階層となる。
　図３は、マルチコアプロセッサシステムのソフトウェア例を示すブロック図である。マルチコアプロセッサシステム１００は、ＯＳが提供するソフトウェアとして、カーネル３０１、スケジューラ３０２、メモリ管理スレッド１２２、ＤＳＰダミーデバイスドライバ３０３、ＧＰＵダミーデバイスドライバ３０４を実行する。また、メモリ管理スレッド１２２は、メインメモリ管理部３１１、ＤＳＰメモリ管理部３１２、ＧＰＵメモリ管理部３１３を含む。
　なお、カーネル３０１、ＤＳＰダミーデバイスドライバ３０３、ＧＰＵダミーデバイスドライバ３０４は、ＣＰＵ＃０、ＣＰＵ＃１それぞれで実行される。具体的に、ＣＰＵ＃０は、カーネル３０１＃０、ＤＳＰダミーデバイスドライバ３０３＃０、ＧＰＵダミーデバイスドライバ３０４＃０を実行する。また、ＣＰＵ＃１は、カーネル３０１＃１、ＤＳＰダミーデバイスドライバ３０３＃１、ＧＰＵダミーデバイスドライバ３０４＃１を実行する。スケジューラ３０２は、ＣＰＵ＃０、ＣＰＵ＃１のいずれが動作してもよいが、本実施の形態ではマルチコアプロセッサシステム１００でのマスタＣＰＵとなるＣＰＵ＃０が実行する。メモリ管理スレッド１２２は、ＣＰＵ＃０、ＣＰＵ＃１のいずれかが実行する。
　カーネル３０１は、ＯＳの中核となる機能を有する。たとえば、カーネル３０１は、アプリが起動された場合、プログラムコードをメインメモリ１０３内に展開する。スケジューラ３０２は、マルチコアプロセッサシステム１００内で実行されるスレッドを各ＣＰＵに割り当て、次に実行するスレッドを選択する機能を有する。たとえば、スケジューラ３０２は、スレッド０をＣＰＵ＃０に割り当て、スレッド１をＣＰＵ＃１に割り当てる。
　ＤＳＰダミーデバイスドライバ３０３、ＧＰＵダミーデバイスドライバ３０４は、それぞれ、ＧＰＵ１０１、ＤＳＰ２０１のデバイスドライバに対するダミーデバイスドライバ１２１である。
　メインメモリ管理部３１１、ＤＳＰメモリ管理部３１２、ＧＰＵメモリ管理部３１３は、それぞれ、メインメモリ１０３、ＤＳＰメモリ２０２、ＧＰＵメモリ１０２を管理する機能を有する。具体的に、メインメモリ管理部３１１、ＤＳＰメモリ管理部３１２、ＧＰＵメモリ管理部３１３は、各メモリの物理アドレス、確保可能な物理アドレス範囲を記憶している。たとえば、メインメモリ管理部３１１は、メインメモリ１０３への確保要求、解放要求に応じて、使用状況を更新する。ＤＳＰメモリ管理部３１２、ＧＰＵメモリ管理部３１３も、それぞれ、ＤＳＰメモリ２０２、ＧＰＵメモリ１０２の使用状況を更新する。
（マルチコアプロセッサシステム１００の機能）
　次に、マルチコアプロセッサシステム１００の機能について説明する。図４は、マルチコアプロセッサシステムの機能例を示すブロック図である。マルチコアプロセッサシステム１００は、格納部４０１と、判断部４０２と、割当部４０３と、上位メモリ管理部４０４と、メモリ管理部４０５と、更新部４１１と、読出部４１２と、選択部４１３と、確保部４１４と、通知部４１５と、を含む。この制御部となる機能（格納部４０１～通知部４１５）は、記憶装置に記憶されたプログラムをＣＰＵ＃０、ＣＰＵ＃１が実行することにより、その機能を実現する。記憶装置とは、具体的には、たとえば、図２に示したＲＯＭ２０４、ＲＡＭ２０５、フラッシュＲＯＭ２０６、フラッシュＲＯＭ２０８などである。
　なお、格納部４０１は、ダミーデバイスドライバ１２１の機能である。また判断部４０２と割当部４０３は、スケジューラ３０２の機能であり、上位メモリ管理部４０４はメモリ管理スレッド１２２の機能であり、メモリ管理部４０５はメインメモリ管理部３１１～ＧＰＵメモリ管理部３１３の機能である。さらに、更新部４１１と読出部４１２と選択部４１３は、上位メモリ管理部４０４に含まれ、確保部４１４と通知部４１５は、メモリ管理部４０５に含まれる。また、図４では、判断部４０２と割当部４０３がＣＰＵ＃０の機能であり、上位メモリ管理部４０４がＣＰＵ＃１の機能として図示されているが、判断部４０２と割当部４０３がＣＰＵ＃１の機能であり、上位メモリ管理部４０４がＣＰＵ＃０の機能であってもよい。
　また、マルチコアプロセッサシステム１００は、管理要求ディスパッチテーブル１２３と、メモリ使用テーブル４２１と、スレッド動作履歴テーブル４２２と、にアクセス可能である。
　管理要求ディスパッチテーブル１２３は、動的に確保可能なメモリであるヒープ領域に存在し、ＣＰＵ＃０、ＣＰＵ＃１、ＧＰＵ１０１、ＤＳＰ２０１で実行されるスレッド情報とメモリ管理要求とを格納している。なお、管理要求ディスパッチテーブル１２３の詳細については、図５にて後述する。メモリ使用テーブル４２１は、メインメモリ１０３、および周辺メモリの空き状況を格納している。なお、メモリ使用テーブル４２１の詳細については、図６にて後述する。スレッド動作履歴テーブル４２２は、各スレッドがどのＣＰＵで動作したかという情報を記憶している。なお、スレッド動作履歴テーブル４２２の詳細については、図７にて後述する。
　格納部４０１は、複数のデータ処理装置または周辺装置で実行されるスレッド情報をヒープ領域にシーケンスに格納する機能を有する。たとえば、格納部４０１は、ＣＰＵ＃０、ＣＰＵ＃１、ＧＰＵ１０１、ＤＳＰ２０１で実行されるスレッド情報を管理要求ディスパッチテーブル１２３に格納する。スレッド情報をシーケンスに格納するとは、スレッド情報を順番に格納していくことである。
　判断部４０２は、複数のデータ処理装置の負荷が均衡状態にあるか否かを判断する機能を有する。たとえば、判断部４０２は、ＣＰＵ＃０とＣＰＵ＃１の負荷が均衡状態にあるか否かを判断する。判断方法の一例として、たとえば、判断部４０２は、ＯＳが有している負荷量判定機能を利用して、スレッドがＣＰＵを占有している時間をＣＰＵごとに算出し、各ＣＰＵの負荷量を基に判断する。各ＣＰＵの負荷量が均等、または、閾値を元に均等と近似できる場合、判断部４０２は、均衡状態であると判断し、各ＣＰＵの負荷量が閾値以上離れた値となった場合、均衡状態にないと判断する。なお、判断結果は、ＲＡＭ２０５、フラッシュＲＯＭ２０６といった記憶領域に記憶される。
　割当部４０３は、判断部４０２によって負荷均衡状態にない場合、上位メモリ管理部４０４、メモリ管理部４０５の実行を、複数のデータ処理装置のうちで負荷の最も小さいデータ処理装置に割り当てる機能を有する。たとえば、割当部４０３は、ＣＰＵ＃０とＣＰＵ＃１が負荷均衡状態にない場合、メモリ管理スレッド１２２を負荷の小さいＣＰＵに割り当てる。
　また、割当部４０３は、判断部４０２によって負荷均衡状態にある場合、上位メモリ管理部４０４、メモリ管理部４０５の実行を、過去に割り当てられたデータ処理装置または周辺装置に割り当ててもよい。たとえば、割当部４０３は、ＣＰＵ＃０とＣＰＵ＃１が負荷均衡状態にある場合、スレッド動作履歴テーブル４２２を参照して、過去に割り当てられたＣＰＵに割り当てる。
　上位メモリ管理部４０４は、メインメモリ１０３および周辺メモリの使用状況を管理する機能を有する。たとえば、上位メモリ管理部４０４は、メモリ管理部４０５にメモリの使用状況を問い合わせ、メモリ管理部４０５から使用状況の通知を受け付ける。
　メモリ管理部４０５は、メモリを管理する機能を有する。メモリ管理部４０５は、メインメモリ１０３、ＧＰＵメモリ１０２、ＤＳＰメモリ２０２、といったメモリごとに存在する。メモリ管理部４０５は、各メモリに対して、論物変換を行って、領域の確保、再確保、解放、リード、ライト等を行う。
　更新部４１１は、通知された使用状況から、メモリ使用テーブル４２１を更新する機能を有する。たとえば、更新部４１１は、メモリ管理部４０５から通知された使用状況をメモリ使用テーブル４２１に格納する。
　読出部４１２は、ヒープ領域からスレッド情報を読み出す機能を有する。たとえば、読出部４１２は、管理要求ディスパッチテーブル１２３からスレッド情報を読み出す。なお、読出結果は、ＲＡＭ２０５、フラッシュＲＯＭ２０６といった記憶領域に記憶される。
　選択部４１３は、ヒープ領域から読み出されるスレッド情報に基づいてスレッド情報に基づくスレッドからのメモリ確保要求に対する確保先を、メモリまたは周辺メモリから選択する機能を有する。また、選択部４１３は、スレッドからのメモリ確保要求に対する確保先を、スレッド情報に基づく優先度情報に基づいて選択してもよい。たとえば、選択部４１３は、優先度が高優先度であれば、高速なメインメモリ１０３を確保先として選択する。また、選択部４１３は、低優先度であれば、メインメモリ１０３より低速なＤＳＰメモリ２０２を確保先に選択する。
　また、選択部４１３は、スレッド情報に基づくスレッドが周辺装置で実行されるスレッドであるとき、メモリ確保要求に対する確保先として、周辺メモリを選択してもよい。なお、選択結果は、ＲＡＭ２０５、フラッシュＲＯＭ２０６といった記憶領域に記憶される。
　確保部４１４は、選択部４１３によって選択された確保先のメモリ内の領域を確保する機能を有する。たとえば、確保部４１４は、メインメモリ１０３が確保先に選択された場合、メインメモリ１０３内の領域を確保する。なお、確保された領域は、要求元のスレッドに通知される。
　通知部４１５は、メモリの使用状況を上位メモリ管理部４０４に通知する機能を有する。たとえば、メインメモリ管理部３１１の機能となる通知部４１５は、メインメモリ１０３の使用状況を上位メモリ管理部４０４に通知する。同様に、ＤＳＰメモリ管理部３１２の機能となる通知部４１５は、ＤＳＰメモリ２０２の使用状況を上位メモリ管理部４０４に通知する。また、ＧＰＵメモリ管理部３１３の機能となる通知部４１５は、ＧＰＵメモリ１０２の使用状況を上位メモリ管理部４０４に通知する。
　図５は、管理要求ディスパッチテーブルの記憶内容の一例を示す説明図である。図５では、管理要求ディスパッチテーブル１２３の記憶内容について説明を行う。管理要求ディスパッチテーブル１２３はメモリごとに存在する。
　本実施の形態では、管理要求ディスパッチテーブル１２３は、メインメモリ１０３、ＧＰＵメモリ１０２、ＤＳＰメモリ２０２、という３つのメモリに対する管理要求を記憶する。メインメモリ１０３の管理要求は管理要求ディスパッチテーブル１２３＿Ｍが記憶し、ＧＰＵメモリ１０２の管理要求は管理要求ディスパッチテーブル１２３＿Ｇが記憶し、ＤＳＰメモリ２０２の管理要求は管理要求ディスパッチテーブル１２３＿Ｄが記憶する。以下、管理要求ディスパッチテーブル１２３＿Ｍについて説明を行うが、管理要求ディスパッチテーブル１２３＿Ｇ、管理要求ディスパッチテーブル１２３＿Ｄも同様の記憶内容となるため、説明を省略する。
　図５で示す管理要求ディスパッチテーブル１２３＿Ｍは、レコード１２３＿Ｍ－１～レコード１２３＿Ｍ－ｎを格納している。ｎは自然数である。管理要求ディスパッチテーブル１２３＿Ｍは、要求元スレッドＩＤ、要求メモリサイズという２つのフィールドを含む。要求元スレッドＩＤフィールドには、メモリ確保要求を行ったスレッドが格納される。要求メモリサイズフィールドには、メモリ確保要求が行われたバイト数が格納される。たとえば、レコード１２３＿Ｍ－１は、スレッド０から３２［バイト］のメモリ確保要求を格納している。
　また、管理要求ディスパッチテーブル１２３＿Ｍは、動的に確保可能なメモリであるヒープ領域に存在し、各レコードがポインタで接続された構造となっている。具体的に、レコード１２３＿Ｍ－１が、レコード１２３＿Ｍ－２へのポインタを有している。同様に、レコード１２３＿Ｍ－２が、レコード１２３＿Ｍ－３へのポインタを有しており、レコード１２３＿Ｍ－３が、レコード１２３＿Ｍ－４へのポインタを有している。また、レコード１２３＿Ｍ－ｎが、レコード１２３＿Ｍ－１へのポインタを有している。
　なお、図５で示した管理要求ディスパッチテーブル１２３は、メモリの管理要求として、メモリ確保要求を図示したが、他のメモリの管理要求として、メモリの再確保要求、メモリの解放要求が含まれてもよい。さらに、メモリの管理要求として、メモリへのリード、ライト要求が含まれてもよい。この場合、管理要求ディスパッチテーブル１２３の１レコードが保持するフィールドとしては、要求元スレッドＩＤフィールドと、各要求の引数と、である。各要求の引数としては、たとえば、メモリの再確保要求であれば、ｒｅａｌｌｏｃ（）関数の引数である、割当済みのアドレスと要求メモリサイズであり、メモリの解放要求であれば、ｆｒｅｅ（）関数の引数である、解放対象のアドレスである。
　図６は、メモリ使用テーブルの記憶内容の一例を示す説明図である。メモリ使用テーブル４２１は、メモリ種別ごとの空き容量を記憶するテーブルである。図６で示すメモリ使用テーブル４２１には、レコード４２１－１～レコード４２１－３が登録されている。また、レコード４２１－１～レコード４２１－３は、ＣＰＵ＃０、ＣＰＵ＃１で実行されるスレッドからのアクセス速度の順序で登録されている。たとえば、図６で示すレコード４２１－１～レコード４２１－３は、降順にて登録されているが、昇順で登録されていてもよい。
　メモリ使用テーブル４２１は、メモリ種別、空き容量という２つのフィールドを含む。メモリ種別フィールドには、各メモリを識別する識別情報が格納される。空き容量フィールドには、メモリの空き容量が格納される。
　たとえば、レコード４２１－１は、メモリ群のうちアクセス速度が最も速いメインメモリ１０３の空き容量が５０［Ｍバイト］であることを示している。次に、レコード４２１－２は、アクセス速度が次に速いＧＰＵメモリ１０２の空き容量が１０［Ｍバイト］であることを示している。最後に、レコード４２１－３は、アクセス速度が遅いＤＳＰメモリ２０２の空き容量が２０［Ｍバイト］であることを示している。
　図７は、スレッド動作履歴テーブルの一例を示す説明図である。スレッド動作履歴テーブル４２２は、スレッドが過去に動作した履歴を記憶するテーブルである。図７で示すスレッド動作履歴テーブル４２２は、レコード４２２－１～４２２－５を格納している。スレッド動作履歴テーブル４２２は、スレッドＩＤ、動作ＣＰＵＩＤという２つのフィールドを含む。スレッドＩＤフィールドは、動作したスレッドのＩＤが格納される。動作ＣＰＵＩＤフィールドには、スレッドが動作したＣＰＵＩＤが格納される。
　たとえば、図７で示すスレッド動作履歴テーブル４２２は、メモリ管理スレッド１２２とスレッド１がＣＰＵ＃１で２回動作しており、スレッド０がＣＰＵ＃０で１回動作していることを示している。
　マルチコアプロセッサシステム１００は、図４で示した機能、図５～図７で示した記憶内容を使用して、スレッドの割当、メモリの確保を行う。図８、図９にて、スレッドの割当方法の一例を示し、図１０、図１１にて、メモリの確保方法の一例を示す。
　図８は、負荷が均衡状態でない場合のスレッド割当方法の一例を示す説明図である。図８で示すマルチコアプロセッサシステム１００は、ＣＰＵ＃０がスレッド０を実行し、ＣＰＵ＃１がスレッド１とスレッド２を実行している。この状態で、メモリ管理スレッド１２２を割り当てる場合、図８のマルチコアプロセッサシステム１００の状態は、各ＣＰＵの負荷が均衡状態にないため、スケジューラ３０２は、負荷の最も小さいＣＰＵにメモリ管理スレッド１２２を割り当てる。
　図９は、負荷が均衡状態である場合のスレッド割当方法の一例を示す説明図である。図９で示すマルチコアプロセッサシステム１００は、ＣＰＵ＃０がスレッド０とスレッド２を実行し、ＣＰＵ＃１がスレッド１とスレッド３を実行している。この状態で、メモリ管理スレッド１２２を割り当てる場合、図９のマルチコアプロセッサシステム１００の状態は、各ＣＰＵの負荷が均衡状態にあるため、スケジューラ３０２は、メモリ管理スレッド１２２が過去に割り当てられたＣＰＵに割り当てる。
　図９の例にて、スケジューラ３０２は、スレッド動作履歴テーブル４２２を参照した結果、メモリ管理スレッド１２２が過去にＣＰＵ＃１で２回動作しているため、メモリ管理スレッド１２２をＣＰＵ＃１に割り当てる。なお、過去の動作履歴に基づくことで、各スレッドは同じＣＰＵに割り当てられることが多くなる。
　次に、メモリ確保方法の一例について図１０、図１１にて説明する。図１０、図１１で示すスレッド０は、メニュープログラムを想定しており、ＧＰＵ１０１を利用し、優先度が中優先度である。スレッド１は、マルチメディアプログラムを想定しており、ＤＳＰ２０１を利用し、優先度が高優先度である。スレッド３は、通信プログラムを想定しており、優先度が低優先度である。
　図１０は、メモリの確保方法の一例を示す説明図（その１）である。初めに、スレッド０を実行するＣＰＵ＃０は、メモリ管理スレッド１２２によってメインメモリ１０３内に割り当てられたスレッド０用領域１００１にアクセスして処理を行っている。なお、スレッド０用領域１００１がメインメモリ１０３内に割り当てられた要因としては、たとえば、割当が行われたときに、ＧＰＵメモリ１０２、ＤＳＰメモリ２０２の空きがなかった場合である。
　次に、ＣＰＵ＃０がスレッド０を実行し、ＣＰＵ＃１が高優先度であるスレッド１を実行する場合、メモリ管理スレッド１２２は、優先度の低いスレッドからメモリ確保要求を行う。図１０の場合では、メモリ管理スレッド１２２は、スレッド０のメモリ確保要求を行った後、スレッド１のメモリ確保要求を行う。
　初めに、メモリ管理スレッド１２２は、ＧＰＵメモリ管理部３１３を実行して、アクセス速度が低速なＧＰＵメモリ１０２内にスレッド０用領域１００２を確保する。次に、メモリ管理スレッド１２２は、メインメモリ管理部３１１を実行して、アクセス速度が高速なメインメモリ１０３内にスレッド１用領域１００３を確保する。
　図１１は、メモリの確保方法の一例を示す説明図（その２）である。図１１で示すマルチコアプロセッサシステム１００は、ＣＰＵ＃０にスレッド０とスレッド２が割り当てられ、ＣＰＵ＃１にスレッド１が割り当てられている。
　このとき、メモリ管理スレッド１２２は、初めにスレッド２のメモリ確保要求を行い、次にスレッド０のメモリ確保要求を行い、最後にスレッド１のメモリ確保要求を行う。初めに、メモリ管理スレッド１２２は、ＤＳＰメモリ管理部３１２を実行して、アクセス速度が低速なＤＳＰメモリ２０２内にスレッド２用領域１１０１を確保する。次に、メモリ管理スレッド１２２は、ＧＰＵメモリ管理部３１３を実行して、アクセス速度が中速なＧＰＵメモリ１０２内にスレッド０用領域１１０２を確保する。最後に、メモリ管理スレッド１２２は、メインメモリ管理部３１１を実行して、アクセス速度が高速なメインメモリ１０３内にスレッド１用領域１１０３を確保する。
　なお、図１１の状態で、ＧＰＵ１０１を利用する新たなスレッドが動作した結果、マルチコアプロセッサシステム１００は、スレッド０用領域１１０２を解放する場合もある。この場合、ＧＰＵを用いるスレッドがＧＰＵ１０１およびＧＰＵメモリ１０２を初期化する。
　図１２は、メモリ管理要求処理手順の一例を示すフローチャートである。メモリ管理要求処理は、各ＣＰＵのダミーデバイスドライバ１２１によって実行されるが、図１２では、ＣＰＵ＃０のダミーデバイスドライバ１２１＃０によって実行されることを想定する。ＣＰＵ＃０は、ユーザスレッドから周辺装置へのアクセス要求を受け付ける（ステップＳ１２０１）。次に、ＣＰＵ＃０は、管理要求ディスパッチテーブル１２３にメモリ管理要求を格納する（ステップＳ１２０２）。続けて、ＣＰＵ＃０は、メモリ管理スレッド１２２に実行要求を通知し（ステップＳ１２０３）、メモリ管理要求処理を終了する。
　図１３は、メモリ管理スレッドの処理手順の一例を示すフローチャートである。メモリ管理スレッド１２２は、後述する図１４で示すスケジューラ３０２の割当先ＣＰＵ選択処理によって、ＣＰＵ＃０、ＣＰＵ＃１のいずれかで実行する。図１３では、メモリ管理スレッド１２２はＣＰＵ＃０に実行されることを想定する。
　ＣＰＵ＃０は、メモリ管理スレッド１２２が定期実行されたか否かを判断する（ステップＳ１３０１）。定期実行された場合（ステップＳ１３０１：Ｙｅｓ）、ＣＰＵ＃０は、各デバイスのメモリ管理部に使用状況、空き状況を問い合わせる（ステップＳ１３０２）。ＣＰＵ＃０は、各デバイスのメモリ管理部として問い合わせを受け付けた後、メモリ管理スレッド１２２に使用状況、空き状況を通知する（ステップＳ１３０３）。通知を受け付けたＣＰＵ＃０は、通知結果から、メモリ使用テーブル４２１を更新し（ステップＳ１３０４）、メモリ管理スレッド１２２の処理を終了する。
　定期実行されていない場合（ステップＳ１３０１：Ｎｏ）、ＣＰＵ＃０は、管理要求ディスパッチテーブル１２３のレコードを読み出す（ステップＳ１３０５）。なお、管理要求ディスパッチテーブル１２３には、複数のレコードが格納されている可能性がある。メモリ確保要求が複数存在する場合、ＣＰＵ＃０は、対応するスレッドの優先度が低いメモリ確保要求から順に読み出してもよい。
　優先度が低いスレッドのメモリを確保した後、優先度が高いスレッドのメモリを確保することで、ＣＰＵ＃０は、高いスレッドのメモリが確保できない場合、低いスレッドのメモリをフラッシュＲＯＭ２０６、フラッシュＲＯＭ２０８にスワップアウトする。このように、確保領域を再配置することで、マルチコアプロセッサシステム１００は、記憶領域が断片化を防ぐことができる。もし、優先度が高いスレッドのメモリから順に確保した場合、優先度の低いスレッドからは、優先度の高いスレッドに対して確保された領域を移動することはできず、記憶領域が断片化するおそれがある。
　レコードの読出後、ＣＰＵ＃０は、読み出したレコードにメモリ確保要求が存在するか否かを判断する（ステップＳ１３０６）。メモリ確保要求が存在する場合（ステップＳ１３０６：Ｙｅｓ）、ＣＰＵ＃０は、メモリ確保先選択処理を実行する（ステップＳ１３０７）。なお、メモリ確保先選択処理は、図１５にて後述する。
　メモリ確保先選択処理実行後、または、メモリ確保要求が存在しない場合（ステップＳ１３０６：Ｎｏ）、ＣＰＵ＃０は、対象となるデバイスのメモリ管理部を実行する（ステップＳ１３０８）。対象となるデバイスのメモリ管理部の実行処理として、たとえば、メモリ管理要求がメモリ確保要求であれば、ＣＰＵ＃０は対象となるメモリに対してメモリ確保を行う。また、対象となるメモリとは、後述するステップＳ１５０４、またはステップＳ１５０５で選択されたメモリとなる。たとえば、メインメモリ１０３が確保先として選択された場合、メインメモリ１０３が対象となるメモリとなる。
　続けて、ＣＰＵ＃０は、読み出した管理要求を処理完了テーブルに移行し（ステップＳ１３０９）、スレッド動作履歴テーブル４２２、負荷情報、メモリ使用テーブル４２１を更新し（ステップＳ１３１０）、メモリ管理スレッド１２２の処理を終了する。なお、処理完了テーブルとは、処理が完了したメモリ管理要求を戻り値と併せて格納するテーブルである。ダミーデバイスドライバ１２１は、処理完了テーブル内のメモリ管理要求に対する戻り値を参照して、呼び元のアプリにメモリ管理要求に対する応答を行う。
　図１４は、スケジューラによる割当対象スレッドの割当先ＣＰＵ選択処理の一例を示すフローチャートである。スケジューラ３０２は、本実施の形態ではＣＰＵ＃０で実行されることを想定している。なお、割当対象スレッドとなり得るスレッドは、ユーザスレッド、メモリ管理スレッド１２２などである。
　ＣＰＵ＃０は、負荷均衡状態が均衡か否かを判断する（ステップＳ１４０１）。負荷が均衡である場合（ステップＳ１４０１：Ｙｅｓ）、ＣＰＵ＃０は、割当対象スレッドが過去に動作したＣＰＵに割当対象スレッドを割り当てる（ステップＳ１４０２）。負荷が均衡でない場合（ステップＳ１４０１：Ｎｏ）、ＣＰＵ＃０は、低負荷ＣＰＵに割当対象スレッドを割り当てる（ステップＳ１４０２）。ステップＳ１４０２、ステップＳ１４０３の終了後、ＣＰＵ＃０は、スレッドの割当先ＣＰＵ選択処理を終了する。
　図１５は、メモリ確保先選択処理の一例を示すフローチャートである。メモリ確保先選択処理は、メモリ管理スレッド１２２と同一のＣＰＵで実行される。ここでは、ＣＰＵ＃０が実行することを想定する。ＣＰＵ＃０は、メモリ管理スレッド１２２の呼び元がユーザスレッドか否かを判断する（ステップＳ１５０１）。
　ユーザスレッドである場合（ステップＳ１５０１：ユーザスレッド）、ＣＰＵ＃０は、続けて、ユーザスレッドが高優先度か否かを判断する（ステップＳ１５０２）。低優先度、中優先度である場合（ステップＳ１５０２：低優先度、中優先度）、ＣＰＵ＃０は、スレッド動作履歴テーブル４２２を参照して、周辺メモリに空きがあるか否かを判断する（ステップＳ１５０３）。
　空きがない場合（ステップＳ１５０３：Ｎｏ）、または、高優先度である場合（ステップＳ１５０２：高優先度）、ＣＰＵ＃０は、メインメモリ１０３と周辺メモリのうち、メインメモリ１０３を確保先として選択する（ステップＳ１５０４）。確保先を選択後、ＣＰＵ＃０は、メモリ確保先選択処理を終了する。空きがある場合（ステップＳ１５０３：Ｙｅｓ）、または、呼び元がデバイスドライバである場合（ステップＳ１５０１：デバイスドライバ）、ＣＰＵ＃０は、メインメモリ１０３と周辺メモリのうち、周辺メモリを確保先として選択する（ステップＳ１５０５）。確保先を選択後、ＣＰＵ＃０は、メモリ確保先選択処理を終了する。
　図１６は、本実施の形態にかかるコンピュータを用いたシステムの適用例を示す説明図である。図１６において、ネットワークＮＷは、サーバ１６０１、サーバ１６０２とクライアント１６３１～クライアント１６３４とが通信可能なネットワークであり、たとえば、ＬＡＮ、ＷＡＮ、インターネット、携帯電話網などを含む。
　サーバ１６０２は、クラウド１６２０を有するサーバ群（サーバ１６２１～サーバ１６２５）の管理サーバである。クライアント１６３１はノート型ＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）である。クライアント１６３２はデスクトップ型ＰＣ、クライアント１６３３は携帯電話機である。携帯電話機として、クライアント１６３３は、スマートフォンであってもよいし、ＰＨＳ（Ｐｅｒｓｏｎａｌ　Ｈａｎｄｙｐｈｏｎｅ　Ｓｙｓｔｅｍ）であってもよい。クライアント１６３４はタブレット型端末である。
　図１６のサーバ１６０１、サーバ１６０２、サーバ１６２１～サーバ１６２５、クライアント１６３１～クライアント１６３４は、たとえば、実施の形態で説明したデータ処理装置として、本実施の形態にかかるデータ処理システムを実行する。たとえば、サーバ１６２１が最も高速なメモリを有し、サーバ１６２２～サーバ１６２５が低速なメモリを有している場合を想定する。このとき、データ処理システムは、サーバ１６２１のメモリを本実施の形態におけるメインメモリ１０３とみなし、サーバ１６２２～サーバ１６２５のメモリを周辺装置のメモリとみなすことで、本実施の形態にかかるデータ処理方法を実行することができる。
　以上説明したように、データ処理システム、およびデータ処理方法によれば、複数のデータ処理装置で実行中のスレッドからのメモリ管理要求を共有メモリに格納し、管理要求を順に読み出し、メインメモリや周辺装置のメモリを確保する。これにより、データ処理システム、複数のデータ処理装置からの、複数アクセスによる競合を発生させずにメモリを管理することができる。具体的には、データ処理装置は、共有メモリから順に読み出すため、メモリ管理要求が同じタイミングで呼び出されることがなく、アクセス競合が発生しない。
　また、データ処理システムは、データ処理装置の負荷が均衡状態にない場合、メモリ管理を行うメモリ管理スレッドを、データ処理装置のうちで負荷の最も小さいデータ処理装置に割り当ててもよい。これにより、データ処理システムは、アクセス競合を起こさずにメモリ管理処理を負荷分散することができる。従来例におけるデータ処理システムでは、任意のデータ処理装置で複数のメモリを管理しようとすると排他制御処理をせねばならず、オーバーヘッドが増加していた。また、従来例におけるデータ処理システムは、１つのデータ処理装置で複数のメモリの管理を行うとすると、負荷が偏ってしまっていた。
　また、データ処理システムは、データ処理装置の負荷が均衡状態にある場合、メモリ管理スレッドを、該当のスレッドが過去に割り当てられたデータ処理装置に割り当ててもよい。これにより、メモリ管理スレッドが割り当てられたデータ処理装置は、キャッシュメモリに残ったスレッドのキャッシュを用いて、高速に処理を行うことができる。
　具体的に、メモリ管理スレッドは、プログラムとしてのメモリ管理ルーチンと、データとして確保したメモリ領域のアロケートテーブルを有する。メモリ管理ルーチンがインストラクションキャッシュに残っていた場合、メモリ管理スレッドは、即座に処理を実行することができる。また、アロケートテーブルがデータキャッシュに残っていた場合、メモリ管理スレッドは、テーブル管理を即座に実行することができる。
　また、データ処理システムは、メモリ確保要求を行ったスレッドの優先度情報に基づいて、メインメモリまたは周辺メモリのいずれかから領域を確保してもよい。また、データ処理システムは、メモリ確保要求を行ったスレッドが高優先度である場合、メモリアクセス速度が速いメモリの領域を確保してもよい。これにより、データ処理システムは、高速処理を求められるスレッドに対しては、高速アクセスが行えるメモリを使用して、高速処理を行うことができる。
　また、データ処理システムは、メモリ確保要求を行ったスレッドが中優先度または低優先度である場合、周辺メモリに空きがあれば、周辺メモリの領域を確保してもよい。周辺メモリは、メインメモリより低速である分、消費電力が小さい。したがって、データ処理システムは、高速処理を行わなくてよい場合、消費電力の小さい周辺メモリを確保することで、消費電力を削減し、電力効率を向上することができる。
　また、データ処理システムは、メモリ確保要求を行ったスレッドが周辺装置を管理するスレッドであれば、周辺メモリの領域を確保してもよい。これにより、データ処理システムは、周辺装置を用いるスレッドであっても、周辺装置に対応するスレッドを実行することができる。
　また、データ処理システムは、メモリおよび周辺メモリの使用状況を収集してもよい。これにより、データ処理システムは、各周辺メモリの空き容量を確認できるため、メモリに空きがあり、低速なメモリから確保していくことができる。
　なお、本実施の形態で説明したデータ処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本データ処理方法を実行するプログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本データ処理方法を実行するプログラムは、インターネット等のネットワークを介して配布してもよい。
　＃０、＃１　ＣＰＵ
　１００　マルチコアプロセッサシステム
　１０１　ＧＰＵ
　１０２　ＧＰＵメモリ
　１０３　メインメモリ
　１２２　メモリ管理スレッド
　１２３　管理要求ディスパッチテーブル
　２０１　ＤＳＰ
　２０２　ＤＳＰメモリ
　４０１　格納部
　４０２　判断部
　４０３　割当部
　４０４　上位メモリ管理部
　４０５　メモリ管理部
　４１１　更新部
　４１２　読出部
　４１３　選択部
　４１４　確保部
　４１５　通知部
　４２１　メモリ使用テーブル
　４２２　スレッド動作履歴テーブル

Claims (12)

  1. 　複数のデータ処理装置と、
    　周辺装置と、
    　前記複数のデータ処理装置および前記周辺装置に共有されるメモリと、
    　前記周辺装置に対応して設けられる周辺メモリと、
    　前記複数のデータ処理装置または前記周辺装置で実行されるスレッド情報をシーケンスに格納するヒープ領域から読み出される前記スレッド情報に基づいて前記スレッド情報に基づくスレッドに前記メモリまたは前記周辺メモリの領域を確保するメモリ管理ユニットと
    　を含むことを特徴とするデータ処理システム。
  2. 　前記複数のデータ処理装置の負荷が均衡状態にないときは、前記メモリ管理ユニットの実行を前記複数のデータ処理装置のうちで負荷の最も小さいデータ処理装置に割り当てるスケジューラを含むこと
    　を特徴とする請求項１に記載のデータ処理システム。
  3. 　前記複数のデータ処理装置の負荷が均衡状態にあるときは、前記スレッド情報に基づくスレッドを前記スレッドが過去に割り当てられたデータ処理装置に割り当てるスケジューラを含むこと
    　を特徴とする請求項１に記載のデータ処理システム。
  4. 　前記メモリ管理ユニットは、前記スレッド情報に基づく優先度情報に基づいて前記スレッドに前記メモリまたは前記周辺メモリの領域を確保すること
    　を特徴とする請求項１乃至請求項３の何れか一に記載のデータ処理システム。
  5. 　前記メモリ管理ユニットは、前記優先度情報が高優先を示すとき、前記スレッドに前記メモリまたは前記周辺メモリのうちでメモリアクセス速度が速いメモリの領域を確保すること
    　を特徴とする請求項４に記載のデータ処理システム。
  6. 　前記メモリ管理ユニットは、前記優先度情報が中優先または低優先を示すとき、前記周辺メモリに空きがあるときは前記スレッドに前記周辺メモリの領域を確保すること
    　を特徴とする請求項４または請求項５に記載のデータ処理システム。
  7. 　前記メモリ管理ユニットは、前記スレッド情報に基づくスレッドが前記周辺装置を管理するスレッドであるとき、前記スレッドに前記周辺メモリの領域を確保すること
    　を特徴とする請求項１乃至請求項６の何れか一に記載のデータ処理システム。
  8. 　前記メモリおよび前記周辺メモリの使用状況を管理する上位メモリ管理ユニットを含み、
    　前記メモリ管理ユニットは、定期的に前記メモリおよび前記周辺メモリの使用状況を前記上位メモリ管理ユニットに通知すること
    　を特徴とする請求項１乃至請求項７の何れか一に記載のデータ処理システム。
  9. 　複数のデータ処理装置のうちの第１データ処理装置は、前記複数のデータ処理装置または周辺装置で実行されるスレッド情報をヒープ領域にシーケンスに格納し、
    　前記ヒープ領域から読み出される前記スレッド情報に基づいて前記スレッド情報に基づくスレッドに前記複数のデータ処理装置で共有されるメモリまたは前記周辺装置に対応する周辺メモリの領域を確保すること
    　を特徴とするデータ処理方法。
  10. 　前記スレッド情報に含まれる優先度情報に基づいて、前記スレッドに前記メモリまたは前記周辺メモリの領域を確保すること
    　を特徴とする請求項９に記載のデータ処理方法。
  11. 　前記優先度情報が高優先を示すとき、前記スレッドに前記メモリまたは前記周辺メモリのうちでメモリアクセス速度が速いメモリの領域を確保すること
    　を特徴とする請求項１０に記載のデータ処理方法。
  12. 　前記優先度情報が中優先または低優先を示すとき、前記周辺メモリに空きがあるときは前記スレッドに前記周辺メモリの領域を確保すること
    　を特徴とする請求項１０または請求項１１に記載のデータ処理方法。
PCT/JP2011/067990 2011-08-05 2011-08-05 データ処理システム、およびデータ処理方法 WO2013021441A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2011/067990 WO2013021441A1 (ja) 2011-08-05 2011-08-05 データ処理システム、およびデータ処理方法
JP2013527764A JP5776776B2 (ja) 2011-08-05 2011-08-05 データ処理システム、およびデータ処理方法
US14/172,005 US9405470B2 (en) 2011-08-05 2014-02-04 Data processing system and data processing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/067990 WO2013021441A1 (ja) 2011-08-05 2011-08-05 データ処理システム、およびデータ処理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/172,005 Continuation US9405470B2 (en) 2011-08-05 2014-02-04 Data processing system and data processing method

Publications (1)

Publication Number Publication Date
WO2013021441A1 true WO2013021441A1 (ja) 2013-02-14

Family

ID=47667994

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/067990 WO2013021441A1 (ja) 2011-08-05 2011-08-05 データ処理システム、およびデータ処理方法

Country Status (3)

Country Link
US (1) US9405470B2 (ja)
JP (1) JP5776776B2 (ja)
WO (1) WO2013021441A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017091444A (ja) * 2015-11-17 2017-05-25 富士通株式会社 情報処理装置、情報処理方法及びプログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10802901B2 (en) * 2016-07-18 2020-10-13 American Megatrends International, Llc Obtaining state information of threads of a device
CN113867963A (zh) * 2021-09-30 2021-12-31 联想(北京)有限公司 一种电子设备及处理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63184601A (ja) * 1987-01-27 1988-07-30 キヤノン株式会社 情報処理装置
WO2007017932A1 (ja) * 2005-08-09 2007-02-15 Fujitsu Limited スケジュール制御プログラム及びスケジュール制御方法
JP2007323393A (ja) * 2006-06-01 2007-12-13 Fuji Xerox Co Ltd 画像処理装置及びプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835906A (en) * 1996-07-01 1998-11-10 Sun Microsystems, Inc. Methods and apparatus for sharing stored data objects in a computer system
US6360303B1 (en) * 1997-09-30 2002-03-19 Compaq Computer Corporation Partitioning memory shared by multiple processors of a distributed processing system
US6289369B1 (en) * 1998-08-25 2001-09-11 International Business Machines Corporation Affinity, locality, and load balancing in scheduling user program-level threads for execution by a computer system
US6341338B1 (en) * 1999-02-04 2002-01-22 Sun Microsystems, Inc. Protocol for coordinating the distribution of shared memory
US7069396B2 (en) * 2002-06-27 2006-06-27 Hewlett-Packard Development Company, L.P. Deferred memory allocation for application threads
US20060078615A1 (en) * 2004-10-12 2006-04-13 Boehringer Ingelheim International Gmbh Bilayer tablet of telmisartan and simvastatin
US8647682B2 (en) * 2006-06-30 2014-02-11 Audrey Kunin Composition and method for treating keratosis pilaris
JP2008108089A (ja) 2006-10-26 2008-05-08 Fujitsu Ltd データ処理システム、タスク制御方法及びそのプログラム
US8886918B2 (en) * 2007-11-28 2014-11-11 International Business Machines Corporation Dynamic instruction execution based on transaction priority tagging
US7802057B2 (en) * 2007-12-27 2010-09-21 Intel Corporation Priority aware selective cache allocation
US8245008B2 (en) * 2009-02-18 2012-08-14 Advanced Micro Devices, Inc. System and method for NUMA-aware heap memory management
US9342374B2 (en) * 2013-06-28 2016-05-17 Dell Products, L.P. Method of scheduling threads for execution on multiple processors within an information handling system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63184601A (ja) * 1987-01-27 1988-07-30 キヤノン株式会社 情報処理装置
WO2007017932A1 (ja) * 2005-08-09 2007-02-15 Fujitsu Limited スケジュール制御プログラム及びスケジュール制御方法
JP2007323393A (ja) * 2006-06-01 2007-12-13 Fuji Xerox Co Ltd 画像処理装置及びプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017091444A (ja) * 2015-11-17 2017-05-25 富士通株式会社 情報処理装置、情報処理方法及びプログラム

Also Published As

Publication number Publication date
JPWO2013021441A1 (ja) 2015-03-05
US9405470B2 (en) 2016-08-02
JP5776776B2 (ja) 2015-09-09
US20140149691A1 (en) 2014-05-29

Similar Documents

Publication Publication Date Title
JP5235989B2 (ja) 仮想マシンのメモリを管理するためのシステム、方法、及びコンピュータ・プログラム
US9779469B2 (en) Register spill management for general purpose registers (GPRs)
US8402470B2 (en) Processor thread load balancing manager
US20230196502A1 (en) Dynamic kernel memory space allocation
US7653799B2 (en) Method and apparatus for managing memory for dynamic promotion of virtual memory page sizes
US20100257331A1 (en) Reducing storage expansion of a virtual machine operating system
WO2021098182A1 (zh) 资源管理方法和装置、电子设备及存储介质
US9501285B2 (en) Register allocation to threads
US9378069B2 (en) Lock spin wait operation for multi-threaded applications in a multi-core computing environment
KR20120017411A (ko) 자원관리방법과 컴퓨터 프로그램제품 및 시스템
EP3748508A1 (en) Memory management in virtualized computing
US9448934B2 (en) Affinity group access to global data
US20110029930A1 (en) Distributed processing device and distributed processing method
JP2018528515A (ja) 効率的な並列コンピューティングのための簡略化されたタスクベースランタイムのための方法
US20190332440A1 (en) Administrative resource management qos for storage appliances
CN115421787A (zh) 指令执行方法、装置、设备、系统、程序产品及介质
JP5776776B2 (ja) データ処理システム、およびデータ処理方法
WO2013008325A1 (ja) マルチコアプロセッサシステム、および制御方法
US9690619B2 (en) Thread processing method and thread processing system for setting for each thread priority level of access right to access shared memory
US9384797B2 (en) Memory control method and system
JP2011221634A (ja) 計算機システム、論理区画管理方法及び論理分割処理プログラム
JP2010097566A (ja) 情報処理装置、及び情報処理システムにおけるバッチ処理の割り当て方法
JP5699665B2 (ja) サーバ装置、処理実行方法およびプログラム
US11928511B2 (en) Systems and methods for prioritizing memory allocation for isolated computing workspaces executing on information handling systems
JP2024002405A (ja) リソース割当プログラムおよびリソース割当方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11870793

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013527764

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11870793

Country of ref document: EP

Kind code of ref document: A1