Electronic device, method, and non-transitory computer-readable recording medium for identifying process for rendering

Abstract

This electronic device may comprise: a display; a processor including a first core operating in a first frequency range, and a second core operating in a second frequency range having a second maximum frequency lower than a first maximum frequency of the first frequency range; and a memory storing instructions and including one or more storage media. The electronic device may identify a request for a first process among at least one process of an application. The electronic device may change a core for processing the first process to the first core among the first core and the second core on the basis of the process indicated by the request being related to a second process for outputting an image to the display. The electronic device may maintain the core for processing the first process on the basis of the process being related to a third process distinguished from the second process.

Description

Electronic device, method, and non-transitory computer-readable recording medium for identifying a process for rendering

[0001] The following descriptions relate to electronic devices, methods, and non-transitory computer-readable recording media for identifying a process for rendering.

[0002] Recently, the proliferation of various types of portable electronic devices, such as smartphones, tablet PCs, wireless earphones, and / or smartwatches, has increased. These portable electronic devices may include a processor (e.g., a central processing unit (CPU)). The processor may include multiple cores operating at various frequencies. These cores operating at various frequencies may be classified into different clusters based on their operating frequency ranges.

[0003] An electronic device is disclosed. The electronic device may include a display, a processor including a first core operating in a first frequency range and a second core operating in a second frequency range having a second maximum frequency less than a first maximum frequency of the first frequency range, and a memory storing instructions, the memory including one or more storage media. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to identify a request from a first process of at least one process of an application. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to change a core for processing the first process to the first core among the first core and the second core, based on whether the process indicated by the request relates to a second process for outputting an image to the display. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to maintain a core for processing the first process based on the process being associated with a third process distinct from the second process.

[0004] A method is disclosed. The method can be performed in an electronic device comprising a display, and a processor including a first core operating in a first frequency range, and a second core operating in a second frequency range having a second maximum frequency less than a first maximum frequency of the first frequency range. The method can include an operation of identifying a request of a first process among at least one process of an application. The method can include an operation of changing a core for processing the first process to the first core among the first core and the second core based on whether the process indicated by the request is related to a second process for outputting an image to the display. The method can include an operation of maintaining the core for processing the first process based on whether the process is related to a third process distinct from the second process.

[0005] A non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium may store one or more programs including instructions. The instructions, when individually or collectively executed by a processor of an electronic device, the processor including a display and a first core operating in a first frequency range and a second core operating in a second frequency range having a second maximum frequency less than a first maximum frequency of the first frequency range, may cause the electronic device to identify a request from a first process of at least one process of an application. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to change a core for processing the first process to the first core among the first core and the second core, based on whether the process indicated by the request relates to a second process for outputting an image to the display. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to maintain a core for processing the first process based on the process being associated with a third process distinct from the second process.

[0006] Figure 1 is a block diagram of an electronic device within a network environment.

[0007] Figure 2 is a block diagram of an electronic device.

[0008] Figure 3 illustrates an example of signal flow between components contained within a memory.

[0009] Figure 4 is a flowchart showing the operation of an electronic device.

[0010] Figure 5 is a flowchart showing the operation of an electronic device.

[0011] Figure 6 is a flowchart showing the operation of an electronic device.

[0012] Figure 7 is a flowchart showing the operation of an electronic device.

[0013] Figure 8 is a flowchart showing the operation of an electronic device.

[0014] Figure 9 is a flowchart showing the operation of an electronic device.

[0015] Figure 10 is a flowchart showing the operation of an electronic device.

[0016] Figure 11 is a flowchart showing the operation of an electronic device.

[0017] Figure 1 is a block diagram of an electronic device (101) within a network environment (100).

[0018] Referring to FIG. 1, in a network environment (100), an electronic device (101) may communicate with an electronic device (102) via a first network (198) (e.g., a short-range wireless communication network), or may communicate with at least one of an electronic device (104) or a server (108) via a second network (199) (e.g., a long-range wireless communication network). The electronic device (101) may communicate with the electronic device (104) via the server (108). The electronic device (101) may include a processor (120), a memory (130), an input module (150), an audio output module (155), a display module (160), an audio module (170), a sensor module (176), an interface (177), a connection terminal (178), a haptic module (179), a camera module (180), a power management module (188), a battery (189), a communication module (190), a subscriber identification module (196), or an antenna module (197). In the electronic device (101), at least one of these components (e.g., the connection terminal (178)) may be omitted, or one or more other components may be added. Some of these components (e.g., the sensor module (176), the camera module (180), or the antenna module (197)) may be integrated into one component (e.g., the display module (160)).

[0019] The processor (120) may, for example, execute software (e.g., a program (140)) to control at least one other component (e.g., a hardware or software component) of the electronic device (101) connected to the processor (120) and perform various data processing or operations. As at least a part of the data processing or operations, the processor (120) may store commands or data received from other components (e.g., a sensor module (176) or a communication module (190)) in a volatile memory (132), process the commands or data stored in the volatile memory (132), and store result data in a non-volatile memory (134). The processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or a secondary processor (123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor)) that may operate independently or together therewith. For example, if the electronic device (101) includes a main processor (121) and a secondary processor (123), the secondary processor (123) may be configured to use less power than the main processor (121) or to be specialized for a specified function. The secondary processor (123) may be implemented separately from the main processor (121) or as a part thereof.

[0020] The auxiliary processor (123) may control at least a part of functions or states associated with at least one component (e.g., a display module (160), a sensor module (176), or a communication module (190)) of the electronic device (101), for example, on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. The auxiliary processor (123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (180) or a communication module (190)). The auxiliary processor (123) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, on the electronic device (101) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0021] The memory (130) can store various data used by at least one component (e.g., processor (120) or sensor module (176)) of the electronic device (101). The data can include, for example, software (e.g., program (140)) and input data or output data for commands related thereto. The memory (130) can include volatile memory (132) or non-volatile memory (134).

[0022] The program (140) may be stored as software in the memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0023] The input module (150) can receive commands or data to be used in a component of the electronic device (101) (e.g., a processor (120)) from an external source (e.g., a user) of the electronic device (101). The input module (150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0024] The audio output module (155) can output audio signals to the outside of the electronic device (101). The audio output module (155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. The receiver can be implemented separately from the speaker or as part of the speaker.

[0025] The display module (160) can visually provide information to an external party (e.g., a user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. The display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0026] The audio module (170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. The audio module (170) can acquire sound through the input module (150), or output sound through an audio output module (155), or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (101).

[0027] The sensor module (176) can detect the operating status (e.g., power or temperature) of the electronic device (101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. The sensor module (176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0028] The interface (177) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (101) to an external electronic device (e.g., the electronic device (102)). The interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0029] The connection terminal (178) may include a connector through which the electronic device (101) may be physically connected to an external electronic device (e.g., electronic device (102)). The connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0030] A haptic module (179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. The haptic module (179) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0031] The camera module (180) can capture still images and videos. The camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0032] The power management module (188) can manage power supplied to the electronic device (101). The power management module (188) can be implemented, for example, as at least a part of a power management integrated circuit (PMIC).

[0033] A battery (189) can power at least one component of the electronic device (101). The battery (189) can include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0034] The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (101) and an external electronic device (e.g., electronic device (102), electronic device (104), or server (108)), and the performance of communication through the established communication channel. The communication module (190) may operate independently from the processor (120) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. The communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (192) can verify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (196).

[0035] The wireless communication module (192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (192) can support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), an external electronic device (e.g., the electronic device (104)), or a network system (e.g., the second network (199)). The wireless communication module (192) can support a peak data rate (e.g., 20 Gbps or more) for realizing eMBB, a loss coverage (e.g., 664 dB or less) for realizing mMTC, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 6 ms or less for round trip) for realizing URLLC.

[0036] The antenna module (197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). The antenna module (197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). The antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (198) or the second network (199), may be selected from the plurality of antennas by, for example, the communication module (190). A signal or power may be transmitted or received between the communication module (190) and the external electronic device through the selected at least one antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (197).

[0037] According to various embodiments, the antenna module (197) may form a mmWave antenna module. The mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0038] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0039] Commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) via a server (108) connected to a second network (199). Each of the external electronic devices (102 or 104) may be the same or a different type of device as the electronic device (101). All or part of the operations executed in the electronic device (101) may be executed in one or more of the external electronic devices (102, 104, or 108). For example, when the electronic device (101) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (101) may, instead of or in addition to executing the function or service on its own, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (101) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server utilizing machine learning and / or a neural network. The external electronic device (104) or the server (108) may be included in the second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0040] Figure 2 is a block diagram of an electronic device.

[0041] The electronic device (101) of FIG. 2 may correspond to the electronic device (101) of FIG. 1. The electronic device (101) of FIG. 2 may include a terminal owned by a user. For example, the terminal may include a personal computer (PC) such as a laptop or desktop, a smartphone, a smartpad, a tablet PC, a smartwatch, and a smart accessory such as a head-mounted device (HMD).

[0042] Referring to FIG. 2, the electronic device (101) may include a processor (120) and a memory (130). The processor (120) of FIG. 2 may be substantially the same as the processor (120) of FIG. 1 or may include the processor (120) of FIG. 1. The memory (130) of FIG. 2 may be substantially the same as the memory (130) of FIG. 1 or may include the memory (130) of FIG. 1.

[0043] The processor (120) of the electronic device (101) may include a plurality of cores (211, 213, 215, 221, 223, 225, 231, 233, 235). Each of the plurality of cores (211, 213, 215, 221, 223, 225, 231, 233, 235) may operate in a designated frequency range. Each of the plurality of cores (211, 213, 215, 221, 223, 225, 231, 233, 235) may be included in one of the plurality of clusters (210, 220, 230) according to the frequency range in which it operates.

[0044] The multiple cores (211, 213, 215, 221, 223, 225, 231, 233, 235) of the processor (120) may have different performances to improve the performance of the electronic device (101) and / or efficiently utilize power. For example, the processor (120) may have a structure (e.g., big-little structure) that includes relatively high-performance cores and relatively low-performance cores. For example, the processor (120) with the big-little structure can extend the battery life by using low-power cores when performing relatively simple tasks. For example, the processor (120) with the big-little structure can provide higher performance to the user by using high-performance cores when performing relatively complex tasks.

[0045] A first cluster (210) may include cores operating in a first frequency range having a first maximum frequency (e.g., 3.4 GHz). A second cluster (220) may include cores operating in a second frequency range having a second maximum frequency (e.g., 3.15 GHz or 2.96 GHz) lower than the first maximum frequency. A third cluster (230) may include cores operating in a third frequency range having a third maximum frequency (e.g., 2.27 GHz) lower than the second maximum frequency. The number of the plurality of clusters (210, 220, 230) is not limited to the three illustrated in FIG. 2. For example, the number of the plurality of clusters (210, 220, 230) may be two. For example, the number of the plurality of clusters (210, 220, 230) may be four or more.

[0046] A cluster (210) operating in a frequency range having the highest maximum frequency (e.g., 3.4 GHz) may be referred to as a prime cluster or a big cluster. A cluster (230) operating in a frequency range having the lowest maximum frequency (e.g., 2.27 GHz) may be referred to as a little cluster or an efficient cluster. A cluster (220) operating in a frequency range having a maximum frequency between the highest and lowest maximum frequencies (e.g., 3.15 GHz or 2.96 GHz) may be referred to as a performance cluster.

[0047] The program (140) of the memory (130) may be classified into a plurality of layers (240, 250, 260). For example, the plurality of layers (240, 250, 260) may include an application layer (240), a framework layer (250), and / or a kernel layer (260). However, the plurality of layers (240, 250, 260) is not limited thereto. For example, the plurality of layers (240, 250, 260) may further include a hardware abstraction layer.

[0048] For example, the application layer (240) may include applications (241, 243). For example, the applications (241, 243) may correspond to the application (146) of FIG. 1.

[0049] For example, the framework layer (250) may include SurfaceFlinger (251), a graphic library (253), and a binder interface (255). For example, SurfaceFlinger (251), a graphic library (253), and a binder interface (255) may correspond to the middleware (144) and / or the operating system (142) of FIG. 1.

[0050] The surface flinger (251) can synthesize at least one image (or layer) (or frame) stored in the frame buffer for each of the applications (241, 243). The surface flinger (251) can synthesize at least one image (or layer) (or frame) stored in the frame buffer at each specified cycle (e.g., cycle according to vsync (e.g., 60 Hz)). Hereinafter, the image (or layer) (or frame) stored in the frame buffer by each of the applications (241, 243) may be referred to as an image.

[0051] The surface flinger (251) can provide a synthesized image (or layer) (or frame) to a display (e.g., the display module (160) of FIG. 1) (via a hardware composer). The image (or layer) (or frame) synthesized by the surface flinger (251) can be referred to as a synthesized image.

[0052] The graphics library (253) may include graphics functions that are basically used in relation to computer graphics. For example, the graphics library (253) may be OpenGL (open graphics library).

[0053] The binder interface (255) may include functions for interfacing programs (e.g., applications (241, 243), SurfaceFlinger (251), graphics library (253), binder interface (255), binder driver (261), scheduler (263), and / or Cgroup (control group) (265)) with the binder driver (261). Interfacing with the binder driver (261) may include calling the binder driver (261) and / or making requests to the binder driver (261).

[0054] For example, the kernel layer (260) may include a binder driver (261), a scheduler (263), and / or a Cgroup (265). For example, the binder driver (261), the scheduler (263), and / or the Cgroup (265) may correspond to the operating system (142) of FIG. 1.

[0055] The binder driver (261) may be a driver for a remote procedure call (or inter-process communication (IPC)) (e.g., a binder call). For example, a remote procedure call (e.g., a binder call) may be executed based on a function (or an application programming interface (API)) defined in the binder interface (255).

[0056] A binder driver (261) can share messages and / or data between processes. The binder driver (261) can identify a remote procedure call (e.g., a binder call) from a first process. The remote procedure call (e.g., a binder call) can be used to pass messages from the first process to a second process, and / or to pass data from the first process to the second process. For example, the binder driver (261) can pass messages and / or data (or pass an address of a memory (130) where messages and / or data are stored) to a second process identified based on a remote procedure call (e.g., a binder call) from the first process.

[0057] The binder driver (261) may transmit messages and / or data based on a remote procedure call (e.g., a binder call) to the scheduler (263) based on the originating process (or caller) and / or the destination process (or callee) of the remote procedure call (e.g., a binder call). In response to the identification of the remote procedure call (e.g., a binder call), the binder driver (261) may transmit identification information of the originating process (or caller) (e.g., a process identification (PID) of the caller) and identification information of the destination process (or callee) (e.g., a PID of the callee) to the scheduler (263).

[0058] The scheduler (263) can schedule tasks of a process (or thread) in a waiting or ready state on the memory (130). The scheduler (263) can assign a unit of time (or time slice) that can occupy a core to a task. For example, if a unit of scheduling time is assigned to a task of a process, the processor (120) can execute the task of the process through the designated core during the unit of time (i.e., for a time of 10 ms). A task is a unit of scheduling.

[0059] The scheduler (263) may include multiple schedulers. For example, the scheduler (263) may include a real time (RT) scheduler and a complete fair scheduler (CFS) scheduler. However, the present invention is not limited thereto. The scheduler (263) may further include a scheduler stop scheduler, a deadline scheduler, and an idle scheduler.

[0060] The scheduler (263) can schedule most general tasks through the CFS scheduler. The scheduler (263) can schedule tasks that need to be continuously processed while occupying the resources of the CPU (or processor (120)) (or core) through the RT scheduler.

[0061] Tasks processed by the RT scheduler (or tasks having RT properties) (hereinafter, referred to as RT tasks) can always be allocated CPU resources with priority compared to tasks processed by the CFS scheduler. In addition, the same RT tasks can be allocated CPU resources in the order in which they entered the run queue (RQ) (e.g., FIFO (first in first out)). Here, the run queue is a memory (or register) within the processor (120), and tasks to be processed by the processor (120) can be stored. The RT task can be at least one of a graphics-related task and an audio-related task that require real-time processing.

[0062] The CFS scheduler can process a general task (or a task having CFS properties) (hereinafter, CFS task) after the RT task operation is finished (or after all RT tasks in the run queue are processed). The CFS task can be scheduled with time distributed according to a nice value. Here, the nice value can indicate an execution priority (e.g., a priority value) among processes running (or loaded) in the user space (270). The CFS scheduler can determine the processing order of the CFS tasks using the priority. Accordingly, a CFS task with a higher priority can be executed (or run) before a CFS task with a lower priority.

[0063] Cgroup (265) can allocate resources (e.g., processor time (or CPU time), memory, and / or network bandwidth) to processes. Cgroup (265) can manage resource allocation information between resources and processes. For example, the resource allocation information can include the ID (identification) of the process (or, process ID (PID)) and / or the ID of the thread (or, thread ID (TID)). At least one thread within a process can have the same PID and a unique TID.

[0064] Programs included in the application layer (240) and / or the framework layer (250) may be executed in the user space (270) of the memory (130). Programs included in the application layer (240) and / or the framework layer (250) may be allocated an independent memory area in the user space (270) of the memory (130). The independence of the memory area may indicate that no processor other than the processor allocated to the memory area may access the area.

[0065] Programs included in the kernel layer (260) can be executed in the kernel space (280). Programs included in the kernel layer (260) can share the memory area of ​​the kernel space (280) of the memory (130). The sharing of the memory area can indicate that the processes of the programs included in the kernel layer (260) can access the memory area.

[0066] The processor (120) can process a task of a process (or thread) using a cluster (or core) allocated (or designated) by the scheduler (263). Here, the process can include one main thread and at least one child thread (or background thread) (or worker thread).

[0067] The main thread can handle user-perceived tasks. These user-perceived tasks may include processing user input. For example, the main thread may acquire user input. For example, the main thread may handle requests to update the user interface (UI). For example, if the main thread determines that a UI update is necessary based on an event (e.g., user input), it may request at least one child thread to update the UI.

[0068] At least one child thread may be a thread for complex calculations or processing large amounts of data. At least one child thread may be created for tasks that require a relatively long processing time compared to the tasks handled by the main thread.

[0069] A UI thread, an example of a child thread, can perform drawing operations. Drawing operations on the UI thread can involve passing a set of commands for drawing an image to another worker thread (e.g., a render thread).

[0070] A render thread, which is an example of a child thread, can draw an image. For example, the render thread can draw an image using a graphics library (253). However, the present invention is not limited thereto. The render thread can draw an image using a built-in graphics library of the program. Here, the graphics library (253) may be a basic graphics library provided by the operating system (142). The built-in graphics library may be a graphics library that is distinct from the basic graphics library provided by the operating system (142). Alternatively, the built-in graphics library may be a graphics library that is not provided by the operating system (142).

[0071] The render thread can update an image in the frame buffer allocated to the application of the render thread. The render thread can send a message to the surface flinger (251) through the binder driver (261) notifying that an image in the frame buffer has been updated.

[0072] The scheduler (263) can schedule a designated process (or thread) (e.g., main thread, surface flinger (251)) through the RT scheduler. For example, a task of a designated process (or thread) (e.g., main thread, surface flinger (251)) may be an RT task.

[0073] The scheduler (263) can schedule a process (or render thread) for rendering through the CFS scheduler. The process (or render thread) for rendering may be a CFS task (or normal task).

[0074] The scheduler (263) may assign the foreground process of the top app to the big cluster. However, if all foreground processes of the top app are assigned to the big cluster, the current consumption of the processor (120) may increase. Accordingly, in order to prevent (or minimize) frame drops of the top app, an operation of assigning some of all foreground processes of the top app to the big cluster may be required. The top app may be an application that has focus among the applications running on the electronic device (101). For example, the top app may be an application that has (or has created) a screen (or view) that receives user input. For example, when screens of two or more applications are displayed on the display, only one application may be the top app. For example, the top app may be an application that has the top-level activity.

[0075] The electronic device (101) can accurately identify the render thread based on a remote procedure call between the render thread and the basic graphics library when the render thread generates an image through the basic graphics library provided by the operating system (142). However, it may be difficult for the electronic device (101) to accurately identify an associated thread (e.g., a thread for loading data (or images) used in the render thread) related to the render thread (or having a dependency on the render thread). Accordingly, the associated thread may not be processed in the big cluster, and in this case, frame drops of the top app may occur due to the associated thread.

[0076] In addition, if the render thread generates an image through a graphics library other than the basic graphics library (e.g., a built-in graphics library of a game application or a built-in graphics library of an Internet browser), the electronic device (101) may have difficulty accurately identifying the render thread. Accordingly, the render thread may not be processed in a large cluster, and in this case, frame drops in the top app may occur due to the render thread.

[0077] Additionally, even if a render thread is specified, if the render thread only updates frames in the frame buffer and its associated thread generates the actual image, the associated thread that generates the actual image may not be processed by the large cluster. In this case, frame drops in the top-level app may occur due to the associated thread.

[0078] Finally, since the name of the render thread can be freely changed by the developer, it may not be easy to specify the render thread through the thread name.

[0079] Accordingly, a method may be required to specify processes and / or threads to perform the actual rendering in the application, and to handle the specified processors and / or threads in a big cluster.

[0080] Hereinafter, referring to FIG. 3, the operation of an electronic device (101) for specifying a process and / or thread for performing actual rendering in an application and for processing the specified processor and / or thread in a big cluster is described.

[0081] Figure 3 illustrates an example of signal flow between components contained within a memory.

[0082] FIG. 3 can be described with reference to FIGS. 1 and 2. The components of FIG. 3 can be included as part of an electronic device (101).

[0083] The binder driver (261) can identify a request (e.g., a remote procedure call) of an application process (310). For example, the request (e.g., a remote procedure call) may be a binder call for message transmission and / or data transmission to a process other than the application process (310). The remote procedure call may include identification information (e.g., a PID) of a caller and identification information (e.g., a PID) of a callee. The request (e.g., a remote procedure call) may include a message and / or data (or an address of a memory (130) where the message and / or data are recorded) for the caller to transmit to the callee. However, the present invention is not limited thereto.

[0084] For example, the binder driver (261) can transmit a request from an application process (310) to a callee. For example, the callee, having received a request from an application process (310), can transmit a response to the request to the caller through the binder driver (261).

[0085] For example, the binder driver (261) may transmit at least a portion of the information included in the request of the application process (310) to the scheduler (263). For example, the binder driver (261) may transmit the caller's identification information and / or the callee's identification information included in the request to the scheduler (263).

[0086] The scheduler (263) may determine a cluster to process the application process (310) based on a request from the application process (310). For example, the scheduler (263) may determine a cluster to process the application process (310) based on at least a portion of information included in a remote procedure call from the binder driver (261) (e.g., caller identification information and / or callee identification information).

[0087] The scheduler (263) can determine whether the application process (310) is a top-app process based on at least a portion of the information (e.g., caller identification information). The scheduler (263) can determine whether the identification information included in the resource allocation information of the top-app managed by the Cgroup (265) corresponds to the caller identification information. The scheduler (263) can determine that the application process (310) is a top-app process based on the correspondence between the identification information included in the resource allocation information of the top-app and the caller identification information.

[0088] The scheduler (263) can determine that the application process (310) is a process of the top app based on the resource allocation information of the top app managed by the Cgroup (265), based on the identification that the resources allocated to the application process (310) are included in the resources for the top app (or the application having the highest activity).

[0089] The scheduler (263) can determine a priority value (or graphic count value) for determining a cluster to process the application process (310) based on the result of determining whether the application process (310) is a top-app process. The priority value (or graphic count value) can be an integer value within a specified range (e.g., 0 to 20).

[0090] The scheduler (263) can determine, based on at least a portion of the information (e.g., identification information of the callee), whether the callee of the request is a specified process (or a processor for outputting an image to a display (e.g., a display module (160) of FIG. 1)) (e.g., Surface Flinger (251)).

[0091] The scheduler (263) can determine whether the identification information included in the resource allocation information of the surface flinger (251) managed by the Cgroup (265) corresponds to the identification information of the callee. The scheduler (263) can determine that the callee is the surface flinger (251) based on the correspondence between the identification information included in the resource allocation information of the surface flinger (251) and the identification information of the callee. The scheduler (263) can determine that the callee is the surface flinger (251) based on the inclusion of the resources allocated to the surface flinger (251) in the resources allocated to the callee.

[0092] The scheduler (263) can determine a priority value (or graphic count value) for determining a cluster to process the application process (310) based on the result of determining whether the callee is a surface flinger (251).

[0093] For example, if the application process (310) that generated the request is a top-app process, the scheduler (263) may increase the priority value of the application process (310) by a specified value (e.g., 2). For example, if the application process (310) that generated the request is not a top-app process, the scheduler (263) may decrease the priority value of the application process (310) by another specified value (e.g., 1).

[0094] For example, the scheduler (263) may increase the priority value of the application process (310) by a specified value (e.g., 2) when the callee is the surface flinger (251). For example, the scheduler (263) may decrease the priority value of the application process (310) by another specified value (e.g., 1) when the callee is not the surface flinger (251).

[0095] For example, the scheduler (263) may increase the priority value of the application process (310) by a specified value (e.g., 2) if all of the plurality of conditions are satisfied. For example, the scheduler (263) may decrease the priority value of the application process (310) by another specified value (e.g., 1) if at least one of the plurality of conditions is not satisfied. Here, the plurality of conditions may include a first condition that the application process (310) that generated the request is a top-app process, and a second condition that the callee is a surface flinger (251).

[0096] The scheduler (263) can determine the cluster of the hardware layer (300) to process the process based on the priority value of the process.

[0097] For example, the scheduler (263) may determine to change the cluster processing the process to a big cluster (e.g., the first cluster (210)) based on the priority value of the process being greater than or equal to a reference value (e.g., 1). For example, the operation of changing the cluster processing the process to a big cluster may be referred to as migration (or big cluster migration). Hereinafter, a process having a priority value greater than or equal to a reference value (e.g., 1) may be referred to as a render process. A process having a priority value less than the reference value (e.g., 1) may be referred to as a non-render process. However, the present invention is not limited thereto.

[0098] For example, the scheduler (263) may decide to keep a cluster processing non-rendering processes based on a priority value being less than a threshold value, but is not limited thereto. For example, the scheduler (263) may change the cluster processing the non-render process to a cluster other than the big cluster (e.g., a little cluster (or an efficiency cluster) (e.g., a third cluster (230)), or a performance cluster (e.g., a second cluster (220)) based on the priority value being lower than the reference value. For example, the scheduler (263) may change the cluster processing the non-render process as the render process is changed to a non-render process as the priority value is changed. For example, the scheduler (263) may change the cluster processing the non-render process to an existing cluster as the render process is changed to a non-render process. Herein, the existing cluster may be a cluster processing the non-render process before the process is identified as a render process according to the priority value. Hereinafter, a cluster other than the big cluster (e.g., a little cluster (or an efficiency cluster), or a performance cluster)) may be referred to as a little cluster.

[0099] The scheduler (263) can change the fallback core of the render process (i.e., the process whose priority value is greater than or equal to the reference value (e.g., 1)). For example, the scheduler (263) can change the fallback core (or fallback cluster) of the render process to a big cluster. Here, the fallback can refer to processing the process in an alternative cluster when the resources of the cluster in which the scheduler (263) processes the process are insufficient (or when the processor usage is greater than or equal to the reference usage). For example, when the resources of the big cluster are insufficient (or when the big cluster usage is greater than or equal to the reference usage), the scheduler (263) can process other processes (or other threads) than the render process (i.e., the process whose priority value is greater than or equal to the reference value (e.g., 1)) among the processes being processed in the big cluster in an alternative processor (e.g., a little cluster).

[0100] An operation of an electronic device (101) processing a rendering process based on the environment of the processor (120) can be exemplified.

[0101] For example, the scheduler (263) may schedule the render process so that the render process is processed before general tasks (or CFS tasks) enqueued in the run queue (RQ) of the big cluster. For example, the scheduler (263) may schedule the render process so that the render process is processed before general tasks enqueued in the run queue (RQ) of the big cluster, based on the number of general tasks enqueued in the run queue (RQ) of the big cluster exceeding a criterion number. For example, the scheduler (263) may schedule the render process so that the render process is processed before general tasks (or CFS tasks) that have a virtual execution time shorter than the virtual execution time (vruntime) of the render process. Here, the virtual execution time may be the expected execution time of each CFS task. For example, the scheduler (263) can schedule CFS tasks other than the render process so that CFS tasks with shorter virtual execution times are processed first.

[0102] For example, the scheduler (263) can process a non-render process based on virtual execution time, based on whether the render process is changed to a non-render process.

[0103] The scheduler (263) can adjust (or increase) the lock order (or waiting order) of the render process. For example, if a lock contention occurs between the render process and another process for the same resource (or data stored in the memory (130)), the processing of the render process may be delayed. The scheduler (263) can adjust (or increase) the order (or waiting order) of the mutex (mutual exclusion, MUTEX) lock of the render process for the resource that the render process and another process are competing for. Accordingly, the render process can quickly acquire the lock for the competing resource. Here, a mutex refers to an object for excluding multiple processes from using one resource at the same time. A mutex lock of a certain process for a certain resource can be understood as the process owning the mutex for the said resource. However, the present invention is not limited thereto. The scheduler (263) can adjust (or increase) the lock order of the render process even in the case of lock situations other than mutex locks (e.g., futex or semaphore).

[0104] For example, the scheduler (263) can determine the order of locks of non-render processes based on the order of requests, based on whether a render process is changed to a non-render process.

[0105] The scheduler (263) may increase the operating frequency of the big cluster based on the identification of the render process. For example, the scheduler (263) may change the operating frequency of the big cluster to the maximum frequency based on the identification of the render process. However, the present invention is not limited thereto. The scheduler (263) may decrease the operating frequency of the big cluster based on the non-identification of the render process. For example, the scheduler (263) may decrease the operating frequency of the big cluster based on the change of all render processes to non-render processes. However, the present invention is not limited thereto. Here, the identification of the render process may include the render process being assigned to be processed in the big cluster.

[0106] In an embodiment, an associated process of a process (or a render process) having a priority value greater than or equal to a reference value (e.g., 1) may be assigned to a big cluster. Here, the associated process may be a process that woke up a process (or a render process) having a priority value greater than or equal to the reference value (e.g., 1). For example, the associated process may be a process that generated a remote procedure call (or interprocess communication) (e.g., a binder call) for the render process.

[0107] For example, the scheduler (263) can manage an association list of associated processes of a render process. For example, if there are multiple render processes, the scheduler (263) can manage an association list of each of the multiple render processes. The association list can be a list of processes that woke up (or called a remote procedure call) the render process. The association list can indicate a specified number of processes (e.g., 5). For example, if the number of associated processes associated with one render process exceeds a specified number (e.g., 5), the scheduler (263) can remove associated processes from the association list in the order of shorter loads (or virtual execution times) of the associated processes. For example, if the number of associated processes associated with one render process exceeds a specified number, the scheduler (263) can maintain a specified number of associated processes in the association list in the order of longer loads (or virtual execution times) of the associated processes.

[0108] For example, the scheduler (263) may change the scheduling policy of the associated process based on whether the render process is maintained. For example, the scheduler (263) may decide to change the cluster processing the associated process to a large cluster (e.g., the first cluster (210)) while the priority value of the render process is greater than or equal to a reference value (e.g., 1).

[0109] For example, the scheduler (263) can change the fallback cluster of an associated process of a render process (or an associated process included in the associated list of render processes) to a big cluster. For example, the scheduler (263) can schedule an associated process of a render process (or an associated process included in the associated list of render processes) to be processed before a general task enqueued in the run queue. For example, the scheduler (263) can adjust (or increase) the lock order of an associated process of a render process (or an associated process included in the associated list of render processes).

[0110] For example, the scheduler (263) may change the fallback cluster of the associated process to a small cluster based on whether the rendering process has changed to a non-rendering process. For example, the scheduler (263) may process the non-rendering process based on the virtual execution time of the associated process based on whether the rendering process has changed to a non-rendering process. For example, the scheduler (263) may determine the lock order of the associated process based on the request order based on whether the rendering process has changed to a non-rendering process.

[0111] In some embodiments, the scheduler (263) may apply the same scheduling policy to the render process when the process communicates with the graphics library (253) (or draws an image via the graphics library (253)). For example, applying the same scheduling policy to the render process may indicate that migration to a big cluster or processing the render process based on the environment of the processor (120) is applied. However, the present invention is not limited thereto.

[0112] Referring to FIG. 3, the above-described example is not limited to an example of a process. Below, a thread for performing actual rendering is specified, and the operation of an electronic device (101) for processing the specified thread in a large cluster is described.

[0113] The binder driver (261) can identify a request (e.g., a remote procedure call) from one of the threads (311, 313, 315, 317, 319) of the application process (310). For example, the request (e.g., a remote procedure call) may be a binder call for message transmission and / or data transmission from the thread to a process other than the application process (310). The remote procedure call may include identification information of the caller (e.g., a PID and a TID) and identification information of the callee (e.g., a PID and a TID). Hereinafter, the thread that generated the request (e.g., a remote procedure call) may be referred to as a first thread.

[0114] For example, the binder driver (261) may transmit at least a portion of the information included in the request of the first thread to the scheduler (263). For example, the binder driver (261) may transmit the caller's identification information and / or the callee's identification information included in the request to the scheduler (263).

[0115] The scheduler (263) may determine a cluster to process the first thread based on a request from the first thread. For example, the scheduler (263) may determine a cluster to process the first thread based on at least a portion of the information included in the remote procedure call from the binder driver (261) (e.g., caller identification information and / or callee identification information).

[0116] The scheduler (263) can determine whether the application process (310) is a thread of the top app based on at least a portion of the information (e.g., the caller's identification information). The scheduler (263) can determine that the application process (310) is a thread of the top app based on a correspondence between the identification information included in the resource allocation information of the top app and the caller's identification information.

[0117] The scheduler (263) can determine that the first thread is a thread of the top app based on the resource allocation information of the top app managed by the Cgroup (265), based on the resource allocated to the first thread (or the application process (310) including the first thread) being identified as being included in the resources for the top app (or the application having the highest activity).

[0118] The scheduler (263) can determine a priority value (or graphic count value) for determining a cluster to process the first thread based on the result of determining whether the first thread is a thread of the top app.

[0119] The scheduler (263) can determine, based on at least a portion of the information (e.g., identification information of the callee), whether the callee of the request is a specified process (or a processor for outputting an image to a display (e.g., a display module (160) of FIG. 1)) (e.g., Surface Flinger (251)).

[0120] The scheduler (263) can determine a priority value (or graphic count value) for determining a cluster to process the application process (310) based on the result of determining whether the callee is a surface flinger (251).

[0121] The scheduler (263) can determine whether the first thread (or the caller thread) is the main thread (311) based on at least a portion of the information (e.g., caller identification information). The scheduler (263) can determine whether the TID of the first thread corresponds to the TID of the main thread (311) based on the TID of each of the threads (311, 313, 315, 317, 319) of the application process (310) managed by the Cgroup (265). The scheduler (263) can determine that the first thread is the main thread (311) based on the TID of the first thread corresponding to the TID of the main thread (311). The scheduler (263) can determine that the first thread is not the main thread (311) based on the fact that the TID of the first thread does not correspond to the TID of the main thread (311) (or is different from the TID of the main thread (311)).

[0122] The scheduler (263) can determine a priority value (or graphic count value) for determining a cluster to process the first thread based on the result of determining whether the first thread is the main thread (311).

[0123] For example, if the first thread is a thread of the top app, the scheduler (263) may increase the priority value of the first thread by a specified value (e.g., 2). For example, if the first thread is not a thread of the top app, the scheduler (263) may decrease the priority value of the first thread by another specified value (e.g., 1).

[0124] For example, the scheduler (263) can increase the priority value of the first thread by a specified value (e.g., 2) when the callee is the surface flinger (251). For example, the scheduler (263) can decrease the priority value of the first thread by another specified value (e.g., 1) when the callee is not the surface flinger (251).

[0125] For example, the scheduler (263) may increase the priority value of the first thread by a specified value (e.g., 2) if the first thread is not the main thread (311). For example, the scheduler (263) may decrease the priority value of the first thread by another specified value (e.g., 1) if the first thread is the main thread (311).

[0126] For example, the scheduler (263) may increase the priority value of the first thread by a specified value (e.g., 2) if all of the plurality of conditions are satisfied. For example, the scheduler (263) may decrease the priority value of the first thread by another specified value (e.g., 1) if at least one of the plurality of conditions is not satisfied. Here, the plurality of conditions may include a first condition that the first thread is a thread of the top app, a second condition that the callee is the surface flinger (251), and a third condition that the first thread is not the main thread (311).

[0127] The scheduler (263) can determine a cluster of hardware layers (300) to process a thread based on the priority value of the thread.

[0128] For example, the scheduler (263) may determine to change the cluster processing the thread to a big cluster (e.g., the first cluster (210)) based on the priority value of the thread being greater than or equal to a reference value (e.g., 1). For example, the operation of changing the cluster processing the thread to a big cluster may be referred to as migration (or big cluster migration). Hereinafter, a thread having a priority value greater than or equal to a reference value (e.g., 1) may be referred to as a render thread. A thread having a priority value less than the reference value (e.g., 1) may be referred to as a non-render thread. However, the present invention is not limited thereto.

[0129] For example, the scheduler (263) may decide to maintain a cluster processing a non-render thread based on a priority value being less than a reference value. However, the present invention is not limited thereto. For example, the scheduler (263) may change the cluster processing a non-render thread to a small cluster other than a big cluster (e.g., a third cluster (230) or a second cluster (220)) based on a priority value being less than a reference value. For example, the scheduler (263) may change the cluster processing a non-render thread as the render thread is changed to a non-render thread due to a change in the priority value. For example, the scheduler (263) may change the cluster processing a non-render thread to an existing cluster as the render thread is changed to a non-render thread. Here, the existing cluster may be a cluster processing a non-render thread before the thread is identified as a render thread based on the priority value.

[0130] The scheduler (263) can change the fallback core of the render thread (i.e., the thread whose priority value is greater than or equal to the reference value (e.g., 1)). For example, the scheduler (263) can change the fallback core (or, fallback cluster) of the render thread to a big cluster. For example, when the resources of the big cluster are insufficient (or, when the usage of the big cluster is greater than or equal to the reference usage), the scheduler (263) can process other threads (or, other threads) than the render thread (i.e., the thread whose priority value is greater than or equal to the reference value (e.g., 1)) among the threads processed in the big cluster on an alternative processor (e.g., a little cluster).

[0131] An operation of an electronic device (101) processing a render thread based on the environment of the processor (120) can be exemplified.

[0132] For example, the scheduler (263) may schedule the render thread so that the render thread is processed before the CFS task enqueued in the run queue (RQ) of the big cluster. For example, the scheduler (263) may schedule the render thread so that the render thread is processed before the CFS task enqueued in the run queue based on whether a standard number of general tasks are enqueued in the run queue (RQ) of the big cluster or more. For example, the scheduler (263) may process the non-render thread based on the virtual execution time based on whether the render thread is changed to a non-render thread.

[0133] The scheduler (263) can adjust (or increase) the lock order (or waiting order) of the render thread. The scheduler (263) can adjust (or increase) the mutex lock order (or waiting order) of the render thread for a resource that the render thread and another thread are competing for. Accordingly, the render thread can quickly acquire the lock for the competing resource. However, the present invention is not limited thereto. The scheduler (263) can adjust (or increase) the lock order of the render thread even in the case of lock situations other than mutex locks (e.g., futex or semaphore). For example, the scheduler (263) can determine the lock order of the non-render thread based on the request order based on the change of the render thread to a non-render thread.

[0134] The scheduler (263) may increase the operating frequency of the big cluster based on the identification of the render thread. For example, the scheduler (263) may change the operating frequency of the big cluster to the maximum frequency based on the identification of the render thread. However, the present invention is not limited thereto. The scheduler (263) may decrease the operating frequency of the big cluster based on the non-identification of the render thread. For example, the scheduler (263) may decrease the operating frequency of the big cluster based on the change of all render threads to non-render threads. However, the present invention is not limited thereto. Here, the identification of the render thread may include the render thread being assigned to be processed in the big cluster.

[0135] In some embodiments, an associated thread of a thread (or a render thread) having a priority value greater than or equal to a reference value (e.g., 1) may be assigned to a big cluster. Here, the associated thread may be a thread that woke up a thread (or a render thread) having a priority value greater than or equal to the reference value (e.g., 1). For example, the associated thread may be a thread that generated a remote procedure call (or inter-thread communication) (e.g., a binder call) to the render thread.

[0136] For example, the scheduler (263) can manage an association list of associated threads of a render thread. For example, when there are multiple render threads, the scheduler (263) can manage an association list of each of the multiple render threads. For example, when the number of associated threads associated with one render thread exceeds a specified number (e.g., 5), the scheduler (263) can remove associated threads from the association list in the order of shorter loads (or virtual execution times) of the associated threads. For example, when the number of associated threads associated with one render thread exceeds a specified number (e.g., 5), the scheduler (263) can maintain a specified number of associated threads in the association list in the order of longer loads (or virtual execution times) of the associated threads.

[0137] For example, the scheduler (263) may change the scheduling policy of the associated thread based on whether the render thread is maintained. For example, the scheduler (263) may decide to change the cluster processing the associated thread to a large cluster (e.g., the first cluster (210)) while the priority value of the render thread is greater than or equal to a reference value (e.g., 1).

[0138] For example, the scheduler (263) can change the fallback cluster of the associated thread of the render thread (or, included in the associated list of the render thread) to a big cluster. For example, the scheduler (263) can schedule the associated thread of the render thread (or, included in the associated list of the render thread) to be processed before the general task enqueued in the run queue. For example, the scheduler (263) can adjust (or increase) the lock order of the associated thread of the render thread (or, included in the associated list of the render thread).

[0139] For example, the scheduler (263) may change the fallback cluster of the associated thread to a small cluster based on whether the render thread has changed to a non-render thread. For example, the scheduler (263) may process the non-render thread based on the virtual execution time of the associated thread based on whether the render thread has changed to a non-render thread. For example, the scheduler (263) may determine the lock order of the associated thread based on the request order based on whether the render thread has changed to a non-render thread.

[0140] In some embodiments, the scheduler (263) may apply the same scheduling policy to the thread as to the render thread when the thread communicates with the graphics library (253) (or draws an image via the graphics library (253)). For example, applying the same scheduling policy to the render thread may indicate that migration to a big cluster or processing of the render thread based on the environment of the processor (120) is applied. However, the present invention is not limited thereto.

[0141] As described above, the electronic device (101) can identify a render process and its associated process (or a render thread and its associated thread) based on a remote procedure call. For example, the electronic device (101) can identify a process (or thread) that actually draws an image even if the process (or thread) does not utilize the graphics library (253) (or the default graphics library provided by the operating system (142)).

[0142] As described above, the electronic device (101) can ensure that the processing of the render process and the identified associated process is not delayed by ensuring that the identified render process and the identified associated process (or the identified render thread and the identified associated thread) are migrated to a big cluster and / or by scheduling them to be processed in the big cluster. Accordingly, the electronic device (101) can reduce the occurrence of frame drops (of the top app) by ensuring that the identified render process and the identified associated process (or the identified render thread and the identified associated thread) are migrated to a big cluster and / or by scheduling them to be processed in the big cluster.

[0143] As described above, the electronic device (101) can reduce (or prevent) excessive current consumption (or excessive energy consumption of the battery) by executing non-render processes (or non-render threads) in a cluster other than the big cluster (e.g., the second cluster (220) or the third cluster (230)) (or not migrating them to the big cluster).

[0144] Figure 4 is a flowchart showing the operation of an electronic device.

[0145] FIG. 4 can be described with reference to FIGS. 1 to 3. The operations of FIG. 4 can be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2.

[0146] Referring to FIG. 4, in operation 410, the electronic device (101) may identify an event. For example, the event may be a remote procedure call (or interprocess communication (IPC)) (e.g., a binder call).

[0147] In operation 420, the electronic device (101) can identify the priority of the caller process. The electronic device (101) can identify the priority of the caller process based on an event. The electronic device (101) can identify the priority of the caller process using the priority value of the caller process identified based on the event. Here, the caller process may be the process that generated the event (or remote procedure call).

[0148] For example, if the caller process is a top-app process, the electronic device (101) may increase the priority value of the caller process by a specified value (e.g., 2). For example, if the caller process that generated the request is not a top-app process, the electronic device (101) may decrease the priority value of the caller process by another specified value (e.g., 1).

[0149] For example, if the called process is SurfaceFlinger (251), the electronic device (101) may increase the priority value of the caller process by a specified value (e.g., 2). For example, if the called process is not SurfaceFlinger (251), the electronic device (101) may decrease the priority value of the caller process by another specified value (e.g., 1).

[0150] For example, if all of the plurality of conditions are satisfied, the electronic device (101) may increase the priority value of the caller process by a specified value (e.g., 2). For example, if at least one of the plurality of conditions is not satisfied, the electronic device (101) may decrease the priority value of the caller process by another specified value (e.g., 1). Here, the plurality of conditions may include a first condition that the caller process that generated the request is a process of the top app, and a second condition that the called process is Surface Flinger (251).

[0151] For example, the electronic device (101) may determine that the priority of the caller process is high based on the priority value of the caller process being greater than or equal to a reference value (e.g., 1). For example, the electronic device (101) may determine that the priority of the caller process is low based on the priority value of the caller process being less than a reference value (e.g., 1).

[0152] In operation 430, the electronic device (101) may allocate cores to process the caller process based on priority. If the priority of the process is high, the electronic device (101) may determine the cluster to process the process as a big cluster. If the priority of the process is low, the electronic device (101) may determine the cluster to process the process as a little cluster.

[0153] Although the operations of FIG. 4 have been described based on processes, they are not limited thereto. For example, the operations of FIG. 4 may be performed based on threads. For example, in operation 420, the electronic device (101) may identify the priority of the caller thread. In this case, the electronic device (101) may consider the condition that the caller thread is not the main thread (311) in order to identify the priority of the caller thread. For example, in operation 430, the electronic device (101) may allocate a core to process the caller thread based on the priority.

[0154] Figure 5 is a flowchart showing the operation of an electronic device.

[0155] FIG. 5 may be described with reference to FIGS. 1 to 4. The operations of FIG. 5 may be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2. The operations of FIG. 5 may be included in operation 420 of FIG. 4.

[0156] Referring to FIG. 5, in operation 510, the electronic device (101) may identify identification information of the caller process. For example, the identification information may include a PID and / or resource information allocated to the caller process.

[0157] In operation 520, the electronic device (101) can determine whether the caller process is a top-app process. The electronic device (101) can determine that the application process (310) is a top-app process based on the correspondence between the PID of the top-app and the PID of the caller process. The electronic device (101) can determine that the application process (310) is a top-app process based on the identification that the resources allocated to the application process (310) are included in the resources for the top-app (or the application having the highest activity).

[0158] Based on determining that the caller process is a top-app process, the electronic device (101) can perform operation 530. Based on determining that the caller process is not a top-app process, the electronic device (101) can perform operation 540.

[0159] In operation 530, the electronic device (101) may increase a count value for identifying the priority of the caller process. For example, the electronic device (101) may increase the count value of the caller process by a specified value (e.g., 2).

[0160] In operation 540, the electronic device (101) may decrement a count value for identifying the priority of the caller process. For example, the electronic device (101) may decrement the count value of the caller process by a specified other value (e.g., 1).

[0161] Although the operations of FIG. 5 have been described based on a process, they are not limited thereto. For example, the operations of FIG. 5 may be performed based on a thread. For example, in operation 510, the electronic device (101) may identify identification information (e.g., PID, TID, and / or resource information) of the caller thread. For example, in operation 520, the electronic device (101) may determine whether the caller thread is a thread of a top app. If the caller thread is a thread of a top app in operation 520, the electronic device (101) may increase a count value for identifying the priority of the caller thread in operation 530. If the caller thread is not a thread of a top app in operation 520, the electronic device (101) may decrease a count value for identifying the priority of the caller thread in operation 540.

[0162] Figure 6 is a flowchart showing the operation of an electronic device.

[0163] FIG. 6 may be described with reference to FIGS. 1 to 5. The operations of FIG. 6 may be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2. The operations of FIG. 6 may be included in operation 420 of FIG. 4.

[0164] Referring to FIG. 6, in operation 610, the electronic device (101) may identify identification information of the called process. For example, the identification information may include a PID and / or resource information allocated to the called process.

[0165] In operation 620, the electronic device (101) can determine whether the called process is a process of Surface Flinger. The electronic device (101) can determine that the called process is a process of Surface Flinger based on the correspondence between the PID of Surface Flinger and the PID of the called process. The electronic device (101) can determine that the called process is a process of Surface Flinger based on the correspondence between the identification information included in the resource allocation information of Surface Flinger and the identification information of the called process.

[0166] Based on determining that the called process is a Surface Flinger process, the electronic device (101) can perform operation 630. Based on determining that the called process is not a Surface Flinger process, the electronic device (101) can perform operation 640.

[0167] In operation 630, the electronic device (101) may increase a count value for identifying the priority of the caller process. For example, if the callee is SurfaceFlinger (251), the scheduler (263) may increase the priority value of the application process (310) by a specified value (e.g., 2).

[0168] In operation 640, the electronic device (101) may decrease a count value for identifying the priority of the caller process. For example, if the callee is not the surface flinger (251), the scheduler (263) may decrease the priority value of the application process (310) by a specified other value (e.g., 1).

[0169] Although the operations of FIG. 6 have been described based on processes, they are not limited thereto. For example, the operations of FIG. 6 may be performed based on threads. For example, in operation 610, the electronic device (101) may identify identification information (e.g., PID, TID, and / or resource information) of a callee thread. For example, in operation 620, the electronic device (101) may determine whether the callee thread is a thread of the Surface Flinger (251). For example, in operation 630, the electronic device (101) may increase a count value for identifying a priority of the caller thread. In operation 640, the electronic device (101) may decrease a count value for identifying a priority of the caller thread.

[0170] Figure 7 is a flowchart showing the operation of an electronic device.

[0171] FIG. 7 may be described with reference to FIGS. 1 to 6. The operations of FIG. 7 may be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2. The operations of FIG. 7 may be included in operation 420 of FIG. 4.

[0172] Referring to FIG. 7, in operation 710, the electronic device (101) may identify identification information of the caller thread. For example, the identification information may include PID, TID, and / or resource information allocated to the caller thread.

[0173] In operation 720, the electronic device (101) can determine whether the caller thread is the main thread. The electronic device (101) can determine that the caller thread is the main thread based on the correspondence between the TID of the main thread and the TID of the caller thread. The electronic device (101) can determine that the caller thread is the main thread based on the identification that the resources allocated to the caller thread are included in the resources for the process of the main thread.

[0174] Based on determining that the caller thread is the main thread, the electronic device (101) can perform operation 730. Based on determining that the caller thread is not the main thread, the electronic device (101) can perform operation 740.

[0175] In operation 730, the electronic device (101) may decrease a count value for identifying the priority of the caller thread. For example, if the first thread is the main thread (311), the scheduler (263) may decrease the priority value of the first thread by a specified other value (e.g., 1).

[0176] In operation 740, the electronic device (101) may increase a count value for identifying the priority of the caller thread. For example, the scheduler (263) may increase the priority value of the first thread by a specified value (e.g., 2) if the first thread is not the main thread (311).

[0177] Figure 8 is a flowchart showing the operation of an electronic device.

[0178] FIG. 8 may be described with reference to FIGS. 1 to 5. The operations of FIG. 8 may be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2. The operations of FIG. 8 may be included in operation 430 of FIG. 4.

[0179] Referring to FIG. 8, in operation 810, the electronic device (101) can identify a count value of the caller process. In operation 820, the electronic device (101) can determine whether the count value is greater than or equal to a reference value (e.g., 1).

[0180] Based on determining that the count value is greater than or equal to the reference value, the electronic device (101) can perform operation 830. Based on determining that the count value is less than the reference value, the electronic device (101) can perform operation 840.

[0181] In operation 830, the electronic device (101) may increase the priority of the caller process.

[0182] For example, the electronic device (101) may assign the caller process to a high-performance core (e.g., a core of a big cluster) based on increasing the priority of the caller process. For example, the electronic device (101) may change the core processing the caller process to a big cluster (e.g., the first cluster (210).

[0183] For example, the electronic device (101) may change the fallback core of the caller process based on increasing the priority of the caller process. For example, the electronic device (101) may change the fallback core (or fallback cluster) of the caller process to a big cluster based on increasing the priority of the caller process.

[0184] For example, the electronic device (101) may schedule the caller process so that the caller process is processed before a general task (or CFS task) enqueued in the run queue (RQ) of the big cluster, based on increasing the priority of the caller process.

[0185] For example, the electronic device (101) may schedule the caller process so that the caller process is processed before general tasks (or CFS tasks) that have a virtual execution time shorter than the virtual execution time (vruntime) of the caller process, based on increasing the priority of the caller process.

[0186] For example, the electronic device (101) can adjust (or increase) the order (or waiting order) of a mutex (mutual exclusion, MUTEX) lock of the caller process for a resource that the caller process and another process are competing for, based on increasing the priority of the caller process.

[0187] In operation 840, the electronic device (101) can maintain the priority of the caller process.

[0188] For example, the electronic device (101) may maintain a core for processing the caller process based on maintaining the priority of the caller process. However, this is not limited thereto. The electronic device (101) may change the core for processing the caller process to a core of a small cluster other than the big cluster (e.g., the third cluster (230) or the second cluster (220)).

[0189] In operation 850, the electronic device (101) may increase the operating speed of the high-performance core. For example, the electronic device (101) may change the operating speed of the high-performance core to the maximum speed. Alternatively, operation 850 may not be performed.

[0190] Although the operations of FIG. 8 have been described based on processes, they are not limited thereto. For example, the operations of FIG. 8 may be performed based on threads. For example, in operation 810, the electronic device (101) may identify a count value of a caller thread. For example, in operation 830, the electronic device (101) may assign the caller thread to a high-performance core (e.g., a core of a big cluster). In operation 840, the electronic device (101) may maintain a core for processing the caller thread.

[0191] Figure 9 is a flowchart showing the operation of an electronic device.

[0192] FIG. 9 may be described with reference to FIGS. 1 to 5. The operations of FIG. 9 may be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2. The operations of FIG. 9 may be performed when operation 830 is performed. For example, the operations of FIG. 9 may be operations performed for the caller process of operation 830.

[0193] Referring to FIG. 9, in operation 910, the electronic device (101) may identify a lock request for a specified resource of a caller process. For example, the requested lock may be a mutual exclusion (MUTEX) lock for an arbitrary resource (or data).

[0194] In operation 920, the electronic device (101) may identify that a lock request is pending. For example, based on the existence of at least one request for a mutex lock on an arbitrary resource (or data) prior to the lock request of the caller process, the electronic device (101) may identify that a lock request is pending.

[0195] In operation 930, the electronic device (101) may increase the priority of the lock request of the caller process. The electronic device (101) may increase the priority of the lock request of the caller process, which is a render process, for a resource that is competing with a non-render process.

[0196] Although the operations of FIG. 9 have been described based on a process, they are not limited thereto. For example, the operations of FIG. 9 may be performed based on a thread. For example, in operation 910, the electronic device (101) may identify a lock request for a specified resource from a caller thread. For example, in operation 930, the electronic device (101) may increase the priority of the lock request from the caller thread.

[0197] Figure 10 is a flowchart showing the operation of an electronic device.

[0198] FIG. 10 may be described with reference to FIGS. 1 to 5. The operations of FIG. 10 may be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2. The operations of FIG. 10 may be included in operations 420 and 430 of FIG. 4.

[0199] Referring to FIG. 10, in operation 1001, the electronic device (101) may identify an event. For example, the event may be a remote procedure call (or interprocess communication (IPC)) (e.g., a binder call).

[0200] In operation 1010, the electronic device (101) can identify identification information of the called process.

[0201] In operation 1020, the electronic device (101) can determine whether the count value of the called process is greater than or equal to a reference value (e.g., 1). For example, the electronic device (101) can determine whether the count value of the called process is greater than or equal to a reference value (e.g., 1) to determine whether the called process is a process with a high priority (or a render process).

[0202] Based on determining that the count value of the called process is greater than or equal to a reference value, the electronic device (101) can perform operation 1030. Based on determining that the count value of the called process is less than or equal to a reference value, the electronic device (101) can perform operation 1040.

[0203] In operation 1030, the electronic device (101) may increase the priority of the caller process.

[0204] For example, the electronic device (101) can assign a caller process to a high-performance core based on increasing the priority of the caller process.

[0205] For example, the electronic device (101) may change the fallback core (or fallback cluster) of the caller process to a big cluster based on increasing the priority of the caller process. For example, the electronic device (101) may schedule the caller process so that the caller process is processed before general tasks (or CFS tasks) enqueued in the run queue (RQ) of the big cluster based on increasing the priority of the caller process. For example, the electronic device (101) may schedule the caller process so that the caller process is processed before general tasks (or CFS tasks) that have a virtual execution time shorter than a virtual execution time (vruntime) of the caller process based on increasing the priority of the caller process. For example, the electronic device (101) can adjust (or increase) the order (or waiting order) of a mutex (mutual exclusion, MUTEX) lock of the caller process for a resource that the caller process and another process are competing for, based on increasing the priority of the caller process.

[0206] According to an embodiment, the electronic device (101) may allocate a caller process included in an association list of callee processes to a high-performance core if the count value of the callee process is greater than or equal to a reference value. Here, the number of caller processes included in the association list may be equal to or less than a specified number (e.g., 5). For example, the association list may include a specified number (e.g., 5) of caller processes in descending order of load (or virtual execution time).

[0207] In operation 1040, the electronic device (101) can maintain the priority of the caller process.

[0208] For example, the electronic device (101) may maintain a core for processing the caller process based on maintaining the priority of the caller process. However, this is not limited thereto. The electronic device (101) may change the core for processing the caller process to a core of a small cluster other than the big cluster (e.g., the third cluster (230) or the second cluster (220)).

[0209] Although the operations of FIG. 10 have been described based on processes, they are not limited thereto. For example, the operations of FIG. 10 may be performed based on threads. For example, in operation 1010, the electronic device (101) may identify a count value of a callee thread. For example, in operation 1030, the electronic device (101) may assign the caller thread to a high-performance core (e.g., a core of a big cluster). In operation 1040, the electronic device (101) may maintain a core for processing the caller thread.

[0210] Figure 11 is a flowchart showing the operation of an electronic device.

[0211] FIG. 11 may be described with reference to FIGS. 1 to 5. The operations of FIG. 11 may be performed by the electronic device (101) (or processor (120)) of FIG. 1 or FIG. 2. The operations of FIG. 11 may be included in operation 1030 of FIG. 10.

[0212] Referring to FIG. 11, in operation 1110, the electronic device (101) may identify an association list of a called process. The electronic device (101) may identify an association list of a called process that is a render process (i.e., a process whose priority value is greater than or equal to a reference value (e.g., 1)). Here, the association list may be a list for managing processes for increasing the priority of a caller process that called the called process. The electronic device (101) may manage an association list for the render process.

[0213] In operation 1120, the electronic device (101) may determine whether a specified condition is met. For example, the specified condition may be a condition for including the caller process in the association list. For example, the specified condition may be a condition for the electronic device (101) to include the caller process in the association list based on the number of processes included in the association list being less than a specified number (e.g., 5).

[0214] For example, the electronic device (101) may determine that a specified condition is met based on the number of processes included in the association list being less than a specified number (e.g., 5). For example, the electronic device (101) may determine that a specified condition is not met based on the number of processes included in the association list being a specified number (e.g., 5).

[0215] The electronic device (101) may perform operation 1130 based on determining that a specified condition is met. The electronic device (101) may perform operation 1140 based on determining that a specified condition is not met.

[0216] In operation 1130, the electronic device (101) may include the caller process in the association list.

[0217] For example, the electronic device (101) may increase the priority of processes included in the association list. For example, the electronic device (101) may increase the priority of a caller process included in the association list based on including the caller process in the association list.

[0218] In operation 1140, the electronic device (101) can identify the load (or virtual execution time) of processes. For example, the electronic device (101) can identify the load (or virtual execution time) of processes included in an association list. For example, the electronic device (101) can identify the load (or virtual execution time) of processes included in the association list and the caller process.

[0219] In operation 1150, the electronic device (101) may update the association list based on the load (or virtual execution time). For example, the electronic device (101) may update the association list so that the association list includes a specified number (e.g., 5) of processes in order of increasing load (or decreasing virtual execution time). For example, the electronic device (101) may update the association list so that the association list includes a specified number (e.g., 5) of processes in order of increasing load among the loads of the processes included in the association list before updating and the loads of the caller process.

[0220] For example, the electronic device (101) may increase the priority of processes included in the association list. For example, the electronic device (101) may increase the priority of a caller process included in the association list based on including the caller process in the association list.

[0221] Although the operations of FIG. 11 have been described based on processes, they are not limited thereto. For example, the operations of FIG. 11 may be performed based on threads. In operation 1110, the electronic device (101) may identify an association list of callee threads. In operation 1130, the electronic device (101) may include the caller thread in the association list. In operation 1140, the electronic device (101) may identify the load (or virtual execution time) of the threads.

[0222] As described above, the electronic device (101) may include a display (160), a processor (120) including a first core (221) driven in a first frequency range and a second core (231) driven in a second frequency range having a second maximum frequency less than a first maximum frequency of the first frequency range, and a memory (130) storing instructions and including one or more storage media. The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to identify a request of a first process among at least one process of an application (241). The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to change the core for processing the first process to the first core (221) among the first core (221) and the second core (231), based on whether the process indicated by the request is related to a second process for outputting an image to the display (160). The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to maintain the core for processing the first process based on whether the process is related to a third process that is distinct from the second process.

[0223] The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to identify a resource allocated to the first process. The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to change a core for processing the first process to the first core (221) based on the identification that the identified resource is included in the resources for the application (241) of the highest activity. The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to maintain a core for processing the first process based on the identification that the identified resource is included in resources other than the resources for the application (241) of the highest activity.

[0224] The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to identify a thread of the first process that generated the request. The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to change a core for processing the thread of the first process to the first core (221) based on the thread being identified as being a thread other than the main thread of the first process. The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to maintain a core for processing the thread of the first process based on the thread being identified as being the main thread of the first process.

[0225] The request may be a request for communication between the first process and the process. The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to transmit at least a portion of the information included in the request to the scheduler (263) via the binder driver (261). The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to determine, via the scheduler (263), based on at least a portion of the information, whether the identified process is related to the second process.

[0226] The above request may be the binder call. The binder call may be an application programming interface (API) for sharing data between the first process and the process, to which independent memory (130) areas of the memory (130) provided by the binder are each allocated.

[0227] The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to identify one or more processes that call the first process based on the process's association with the second process. The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to change the core for processing the one or more processes to the first core (221).

[0228] The above instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to assign the first core (221) as a fallback core of the first process based on the process being associated with the second process.

[0229] The above instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to prioritize processing of the first process over a plurality of processes waiting in a queue associated with the first core (221) based on the process being associated with the second process.

[0230] The above instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to increase the operating frequency of the first core (221) within the first frequency range based on changing the core for processing the first process to the first core (221).

[0231] The above instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to increase the priority of a mutual exclusion lock of the first process for a designated resource based on the process's association with the second process.

[0232] The second process may be a process of a surface flinger for synthesizing at least one image stored in a frame buffer.

[0233] As described above, the method can be performed in an electronic device (101) including a display (160), and a processor (120) including a first core (221) driven in a first frequency range, and a second core (231) driven in a second frequency range having a second maximum frequency less than a first maximum frequency of the first frequency range. The method can include an operation of identifying a request of a first process among at least one process of an application (241). The method can include an operation of changing a core for processing the first process to the first core (221) among the first core (221) and the second core (231) based on whether the process indicated by the request is related to a second process for outputting an image to the display (160). The method can include an operation of maintaining the core for processing the first process based on whether the process is related to a third process that is distinct from the second process.

[0234] The method may include an operation of identifying a resource allocated to the first process. The method may include an operation of changing a core for processing the first process to the first core (221) based on the identification that the identified resource is included in the resources for the application (241) of the top-level activity. The method may include an operation of maintaining the core for processing the first process based on the identification that the identified resource is included in resources other than the resources for the application (241) of the top-level activity.

[0235] The method may include an operation of identifying a thread of the first process that generated the request. The method may include an operation of changing a core for processing the thread of the first process to the first core (221) based on the identification that the thread is a thread other than the main thread of the first process. The method may include an operation of maintaining a core for processing the thread of the first process based on the identification that the thread is the main thread of the first process.

[0236] The above request may be a request for communication between the first process and the above process. The method may be an operation of transmitting at least a portion of the information included in the request to the scheduler (263) via the binder driver (261). The method may include an operation of determining, via the scheduler (263), whether the identified process is related to the second process based on at least a portion of the information.

[0237] The above request may be the binder call. The binder call may be an application programming interface (API) for sharing data between the first process and the process, to which independent memory (130) areas of the memory (130) provided by the binder are each allocated.

[0238] The method may include an operation of identifying one or more processes that call the first process based on the relationship of the process to the second process. The method may include an operation of changing the core for processing the one or more processes to the first core (221).

[0239] The method may include an operation of allocating the first core (221) as a fallback core of the first process based on the process being related to the second process.

[0240] The second process may be a process of a surface flinger for synthesizing at least one image stored in a frame buffer.

[0241] As described above, a non-transitory computer-readable recording medium can store one or more programs including instructions. The instructions, when individually or collectively executed by a processor (120) of an electronic device (101) including a display (160), and a first core (221) operating in a first frequency range, and a second core (231) operating in a second frequency range having a second maximum frequency less than a first maximum frequency of the first frequency range, can cause the electronic device (101) to identify a request of a first process among at least one process of an application (241). The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to change the core for processing the first process to the first core (221) among the first core (221) and the second core (231), based on whether the process indicated by the request is related to a second process for outputting an image to the display (160). The instructions, when individually or collectively executed by the at least one processor (120), may cause the electronic device (101) to maintain the core for processing the first process based on whether the process is related to a third process that is distinct from the second process.

[0242] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices are not limited to the aforementioned devices.

[0243] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another component (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0244] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0245] Various embodiments of the present document may be implemented as software (e.g., a program (140)) including one or more instructions stored in a storage medium (e.g., an internal memory (136) or an external memory (138)) readable by a machine (e.g., an electronic device (101)). For example, a processor (e.g., a processor (120)) of the machine (e.g., an electronic device (101)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0246] The methods according to various embodiments disclosed in this document may be provided as included in a computer program product. The computer program product may be traded as a commodity between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0247] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In an electronic device (101), Display (160), A processor (120) including a first core (221) driven in a first frequency range, and a second core (231) driven in a second frequency range having a maximum frequency less than the maximum frequency of the first frequency range, and A memory (130) for storing instructions, wherein the instructions, when executed, cause the electronic device to: Identify the request of the first process (310) of the application (241), Based on the fact that the process indicated by the above request is related to a process for outputting an image to the display (160), the first core is allocated to process the first process, Causing the core currently assigned to the first process to be maintained as a core for processing the first process, based on the process indicated by the request being related to a process other than the process for outputting an image to the display. Electronic devices.

2. In claim 1, The above instructions cause the electronic device to: Identify the resources allocated to the first process (310), Based on the above identified resource being included in the resources for the application (241) having the highest activity among multiple applications, the first process is allocated to a core for processing, Based on the above identified resource being included in the resources other than the resources for the application (241) having the above top activity, causing the core currently allocated to the first process to be maintained as a core for processing the first process. Electronic devices.

3. In claim 1 or 2, The above instructions cause the electronic device to: Identify the thread of the first process (310) that generated the above request, Based on the identification that the thread is a thread other than the main thread of the first process, assigning a core for processing the thread of the first process; Based on the identification that the thread is the main thread of the first process, causing the core currently assigned to the thread of the first process to be maintained as a core for processing the thread of the first process. Electronic devices.

4. In claim 1, 2, or 3, The above request is a request for communication between the first process and the process indicated by the request, The above instructions cause the electronic device to: Through the binder driver (261), at least a portion of the information included in the request is transmitted to the scheduler (263), Causing the scheduler (263) to determine, based on at least a portion of the information, whether the indicated process is related to the process for outputting an image to the display. Electronic devices.

5. In claim 4, The above request is the above binder call, The above binder call is an API (application programming interface) for sharing data between the first process and the process indicated by the request, each of which is allocated independent memory (130) areas of the memory (130) provided by the binder. Electronic devices.

6. In any of the preceding claims, The above instructions cause the electronic device to: Identifying one or more processes that call the first process based on the process indicated by the request being related to the process for outputting an image to the display; causing one or more of the above processes to be assigned to the first core (221); Electronic devices.

7. In any of the preceding claims, The above instructions cause the electronic device to: Based on the fact that the process indicated by the request is related to the process for outputting an image to the display, causing the first core (221) to be allocated as a fallback core of the first process, Electronic devices.

8. In any of the preceding claims, The above instructions cause the electronic device to: Causing the first process to be processed with priority over a plurality of processes waiting in a queue associated with the first core (221), based on the fact that the process indicated by the request is related to the process for outputting an image to the display. Electronic devices.

9. In any of the preceding claims, The above instructions cause the electronic device to: Based on changing the core for processing the first process to the first core (221), causing the operating frequency of the first core (221) to increase within the first frequency range. Electronic devices.

10. In any of the preceding claims, The above instructions cause the electronic device to: Causing the first process to increase the priority of its mutual exclusion lock on the specified resource based on the process indicated by the request being related to the process for outputting an image to the display. Electronic devices.

11. In any of the preceding claims, The above process for outputting an image to the above display is a process of the surface flinger for synthesizing at least one image stored in the frame buffer. Electronic devices.

12. A method performed in an electronic device (101) including a processor (120) including a display (160), a first core (221) driven in a first frequency range, and a second core (231) driven in a second frequency range having a maximum frequency less than the maximum frequency of the first frequency range, An action that identifies a request from the first process (310) of the application; An operation of allocating the first core for processing the first process based on the process indicated by the above request being related to a process for outputting an image to the display (160), and An operation of maintaining a core currently allocated to the first process as a core for processing the first process, based on the process indicated by the request being related to a process other than the process for outputting an image to the display. method.

13. In claim 12, An action to identify resources allocated to the first process; An operation of allocating the identified resource to a core for processing the first process based on the resource being included in the resource for an application having the highest activity among multiple applications, and An operation of maintaining a core currently allocated to the first process as a core for processing the first process, based on the identified resource being included in a resource other than the resource for the application having the top activity. method.

14. In claim 12, An action to identify the thread of the first process that generated the request; An operation of allocating a core for processing the thread of the first process based on the identification that the thread is a thread other than the main thread of the first process, and An operation including maintaining a core currently assigned to the thread of the first process as a core for processing the thread of the first process based on the thread being identified as the main thread of the first process. method.

15. A computer program arranged to perform a method according to any one of claims 12 to 14 when executed by a processor.

Images