Electronic device and method for resource management

Abstract

An electronic device according to one embodiment of the present disclosure can: identify, in response to a request for execution of an application, at least one service associated with the application; determine a first scheduling policy and a second scheduling policy to be applied to at least one process associated with the at least one service; apply, to the at least one process, the first scheduling policy, which corresponds to the higher scheduling priority from among the first scheduling policy and the second scheduling policy; and release the first scheduling policy in response to generation of an application process executing the application, and apply the second scheduling policy to the at least one process.

Description

Electronic devices and methods for resource management

[0001] The present disclosure relates to an electronic device and method for resource management.

[0002] As technology advances and advances, electronic devices can offer a variety of functions beyond their traditional capabilities. For example, a television (TV) can not only display broadcast channels, but also run applications, access websites, or communicate with other electronic devices.

[0003] Users can launch applications after turning on the TV. For example, a user can power on the TV and launch an application providing an over-the-top (OTT) service by pressing a key on the remote control. This key-driven application launch can be performed at various speeds (e.g., fast or slow) based on the boot performance of the TV, which displays the initial screen when turned on, and the application's execution performance.

[0004] Typically, in electronic devices, the higher the boot performance (the first screen displayed when the TV is turned on), the lower the application execution performance. Conversely, the lower the boot performance, the higher the application execution performance. Therefore, there is a need for a method to improve application execution performance while maintaining boot performance.

[0005] Meanwhile, if resource management is not properly performed in electronic devices, CPU (central processing unit) contention or priority inversion can occur between processes associated with an application. CPU contention refers to competition between processes for CPU resources, while priority inversion can refer to a situation where a lower-priority process is delayed, thereby delaying the execution of a higher-priority process associated with it. Both CPU contention and priority inversion can delay application execution. Therefore, a resource management technology that can prevent or mitigate these problems while enabling faster application execution is needed.

[0006] One embodiment of the present disclosure may provide an electronic device and method for resource management.

[0007] One embodiment of the present disclosure can provide an electronic device and method that can execute an application selected by a user more quickly after a cold boot.

[0008] One embodiment of the present disclosure may provide an electronic device and method that can improve CPU contention or priority inversion.

[0009] According to an exemplary embodiment of the present disclosure, a device comprises: an electronic device; a memory storing at least one program; and at least one processor electrically connected to the memory and configured to execute at least one instruction of the program stored in the memory. The at least one processor may be configured to, individually and / or collectively: in response to a request for execution of an application, identify at least one service associated with the application; determine a first scheduling policy and a second scheduling policy to be applied to at least one process associated with the at least one service; apply the first scheduling policy corresponding to a higher scheduling priority among the first scheduling policy and the second scheduling policy to the at least one process; and in response to an application process executing the application being created, release the first scheduling policy and apply the second scheduling policy to the at least one process.

[0010] According to an exemplary embodiment, the first scheduling policy includes a policy for preferentially allocating a first resource to the at least one process, and the second scheduling policy includes a policy for allocating a second resource to the at least one process based on a set resource allocation ratio, wherein the set resource allocation ratio may correspond to at least one control group including the at least one process among a plurality of control groups.

[0011] According to an exemplary embodiment, at least one processor may be configured to, individually and / or collectively: in response to the application process being created, apply the first scheduling policy to the application process; and in response to a set amount of time elapsed from the time the first scheduling policy was applied to the application process, release the first scheduling policy applied to the application process and apply the second scheduling policy to the application process.

[0012] According to an exemplary embodiment, at least one processor may be configured to, individually and / or collectively: in response to a need for communication between processes at a given point in time, identify a first process among the processes, including a communication requesting process, and a second process among the processes, including a communication responding process, compare a first scheduling priority of the first process with a second scheduling priority of the second process, and, in response to the first scheduling priority being higher than the second scheduling priority, inherit the first scheduling priority to the second process.

[0013] According to an exemplary embodiment, the first process may correspond to the application process, and the second process may correspond to any one of the at least one process.

[0014] According to an exemplary embodiment, at least one processor may be configured to individually and / or collectively: determine whether a set amount of time has elapsed since the first scheduling priority was inherited by the second process, and in response to the set amount of time having elapsed, release the inheritance of the first scheduling priority for the second process.

[0015] According to an exemplary embodiment, the first scheduling priority may be determined based on the first scheduling policy to preferentially allocate the first resource to the first process, and the second scheduling priority may be determined based on the second scheduling policy to allocate the second resource corresponding to the set resource allocation ratio to the second process.

[0016] According to an exemplary embodiment, the second process may be registered as a priority inheritance target process.

[0017] According to an exemplary embodiment, at least one processor may be configured, individually and / or collectively: in response to the first process being identified as a plurality, to identify a third scheduling priority corresponding to a highest priority among scheduling priorities of each of the first processes, to compare the third scheduling priority to a second scheduling priority of the second process, and in response to the third scheduling priority being higher than the second scheduling priority, to inherit the third scheduling priority to the second process.

[0018] According to an exemplary embodiment of the present disclosure, a method for managing resources by an electronic device may include: in response to a request for execution of an application, identifying at least one service associated with the application; determining a first scheduling policy and a second scheduling policy to be applied to at least one process associated with the at least one service; applying the first scheduling policy corresponding to a higher scheduling priority among the first scheduling policy and the second scheduling policy to the at least one process; and in response to an application process for executing the application being created, releasing the first scheduling policy and applying the second scheduling policy to the at least one process.

[0019] According to an exemplary embodiment, the first scheduling policy includes a policy for preferentially allocating a first resource to the at least one process, and the second scheduling policy includes a policy for allocating a second resource to the at least one process based on a set resource allocation ratio, wherein the set resource allocation ratio may correspond to at least one control group including the at least one process among a plurality of control groups.

[0020] According to an exemplary embodiment, the method may further include, in response to the creation of the application process, applying the first scheduling policy to the application process; and in response to a set time elapsed from the time at which the first scheduling policy was applied to the application process, releasing the first scheduling policy applied to the application process and applying the second scheduling policy to the application process.

[0021] According to an exemplary embodiment, the method may further include, in response to a need for communication between processes at a given point in time, identifying a first process including a communication request process among the processes and a second process including a communication response process among the processes; comparing a first scheduling priority of the first process with a second scheduling priority of the second process; and, in response to the first scheduling priority being higher than the second scheduling priority, inheriting the first scheduling priority to the second process.

[0022] According to an exemplary embodiment, the first process may correspond to the application process, and the second process may correspond to any one of the at least one process.

[0023] According to an exemplary embodiment, the method may further include: determining whether a set time has elapsed since the first scheduling priority was inherited by the second process; and, in response to the set time having elapsed, releasing the inheritance of the first scheduling priority for the second process.

[0024] According to an exemplary embodiment, the first scheduling priority may be determined based on the first scheduling policy to preferentially allocate the first resource to the first process, and the second scheduling priority may be determined based on the second scheduling policy to allocate the second resource corresponding to the set resource allocation ratio to the second process.

[0025] According to an exemplary embodiment, the second process may be registered as a priority inheritance target process.

[0026] According to an exemplary embodiment, the method may further include: in response to the first process being identified as being a plurality of, identifying a third scheduling priority corresponding to a highest priority among scheduling priorities of each of the first processes; comparing the third scheduling priority with a second scheduling priority of the second process; and in response to the third scheduling priority being higher than the second scheduling priority, inheriting the third scheduling priority to the second process.

[0027] The technical problems to be achieved in the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned above can be derived from the exemplary embodiments of the present disclosure by a person having ordinary knowledge in the relevant technical field.

[0028] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0029] FIG. 1 is a graph exemplarily showing the relationship between booting performance and application execution performance of an electronic device according to one embodiment.

[0030] FIG. 2 is a graph illustrating exemplary task processing delays caused by CPU contention according to one embodiment.

[0031] FIG. 3 is a diagram illustrating an example in which priority inversion occurs between processes according to one embodiment.

[0032] FIG. 4 is a graph illustrating exemplary context switch latency that may occur according to a scheduling scheme according to one embodiment.

[0033] FIG. 5 is a signal flow diagram illustrating an execution process of an application in an electronic device according to one embodiment.

[0034] FIG. 6 is an exemplary system architecture diagram for CPU resource management of an electronic device according to one embodiment.

[0035] FIG. 7 is a schematic diagram illustrating priority inheritance operation between processes according to one embodiment.

[0036] FIG. 8 is a graph illustrating an example in which a duplicate boosting operation is performed according to one embodiment.

[0037] FIG. 9 is a graph illustrating another example in which a duplicate boosting operation is performed according to one embodiment.

[0038] FIG. 10 is a flowchart illustrating a resource management operation of an electronic device according to one embodiment.

[0039] FIG. 11 is a flowchart illustrating a duplicate boosting operation applied to an application process according to one embodiment.

[0040] FIG. 12 is a flowchart illustrating a priority inheritance operation between a first process and a second process according to one embodiment.

[0041] FIG. 13 is a flowchart illustrating a priority inheritance release operation between a first process and a second process according to one embodiment.

[0042] FIG. 14 is a flowchart illustrating priority inheritance operations between multiple first processes and second processes according to one embodiment.

[0043] FIG. 15 is a block diagram of an exemplary electronic device according to one embodiment.

[0044] Figure 16 is a graph showing an exemplary execution performance of application A according to one embodiment.

[0045] Figure 17 is a graph showing an exemplary execution performance of application B according to one embodiment.

[0046] Figure 18 is a graph showing exemplary boot performance and application execution performance according to one embodiment.

[0047] In this disclosure and drawings, the same or similar reference numerals may be used for the same or similar components.

[0048] Hereinafter, various embodiments of the present disclosure will be described in detail with reference to the drawings. However, the present disclosure may be implemented in various different forms and is not limited to the various embodiments described herein. In addition, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and conciseness.

[0049] Electronic devices (e.g., TVs) can run a user-selected application after a cold boot. A cold boot (or cold boot) can refer to, for example, an electronic device that is powered on and running, then powered off and then powered on again to boot.

[0050] Suspend-to-RAM (random access memory) technology can be used to improve the booting performance of electronic devices. Suspend-to-RAM technology can refer to a technology that stores information (e.g., system information) in RAM just before the electronic device is powered off, and maintains the information stored in RAM with a certain current (e.g., a low current below a threshold). When the electronic device is powered off and then powered back on, the information stored in RAM just before the electronic device is powered off can be used based on Suspend-to-RAM technology to quickly display the initial screen (e.g., home screen) of the electronic device.

[0051] When Suspend-to-RAM technology is used in electronic devices, boot times can be reduced, and delays in application execution due to power-on / off times can be prevented or reduced. However, Suspend-to-RAM technology may not be used in some cases, as information stored in RAM cannot be retained if the user physically (or manually) turns off the electronic device, such as by unplugging the power cord, or if the electronic device is a portable electronic device that uses a battery.

[0052] Electronic devices can quickly launch user-selected applications after a cold boot by considering both boot performance and application execution performance. Boot performance and application execution performance can have a relationship, for example, as shown in Figure 1.

[0053] FIG. 1 is a graph showing an exemplary relationship between booting performance and application execution performance of an electronic device according to one embodiment.

[0054] Referring to FIG. 1, boot performance may be associated with a cold boot time (102), and application execution performance may be associated with an app execution time (104). The cold boot time (102) may be identified as the time from the time power is applied (e.g., supplied) to the electronic device (or the time power is turned on) to the time the boot process is completed and the screen is first displayed. The app execution time (104) may be identified as the time from the time a user input related to application execution is received to the time the application is executed.

[0055] As shown in FIG. 1, a shorter cold boot time (102) may be correlated with a longer app execution time (104), and a longer cold boot time (102) may be correlated with a shorter app execution time (104). For example, a shorter cold boot time (102) may result in an incomplete operating system (OS) initialization (or system initialization), which may result in a longer app execution time (104). For example, a longer cold boot time (102) may result in a shorter app execution time (104), which may result in a more complete or more frequent OS initialization. Therefore, booting performance and application execution performance based on the cold boot time (102) and the app execution time (104) may have a trade-off (e.g., complementary) relationship. Considering this relationship, a resource management technology that can satisfy both booting performance and application execution performance may be required in electronic devices.

[0056] An electronic device can perform scheduling (e.g., scheduling operations) for resource management, thereby allocating resources to an application to be executed and at least one service. For example, at least one service may be associated with the application to be executed, and the resource may include a central processing unit (CPU) resource. For convenience and simplicity, the following description assumes that the resource is a CPU resource. However, the resource is not limited to CPU resources and may also include other types of resources (e.g., memory).

[0057] If sufficient CPU resources are not allocated to the application and at least one service being executed, CPU contention or priority inversion may occur between the processes associated with the application. CPU contention and priority inversion can lead to delays in application execution.

[0058] CPU contention can refer to CPU resource competition, where multiple processes (or threads) compete for CPU resources. CPU contention can occur when multiple processes are not allocated the required amount of CPU resources. Processes that fail to compete for CPU resources may have to wait until they are allocated CPU resources. In this case, the process's task processing may be delayed.

[0059] FIG. 2 is a graph illustrating exemplary task processing delays caused by CPU contention according to one embodiment.

[0060] Referring to FIG. 2, a process that is not allocated resources in CPU contention may experience a delay in task processing. For example, if a task associated with the process has a processing time (or work time) (202) of 3 seconds and waits 5 seconds until resources are allocated in CPU contention, the processing of the task may be completed after 8 seconds have elapsed. In other words, the time for the task to be processed may be delayed by the 5-second delay time (204). The delay in task processing may cause inconvenience to the user. For example, if the task is related to processing key inputs from a TV remote control, the user may feel inconvenience due to a delay in the response to the key inputs from the TV remote control.

[0061] An application requested by a user to run may operate with the goal of rapid screen display. The application process executing the application may not be able to perform (or process) all functions on its own. In this case, the application process may request necessary functions from at least one service process associated with the service. For example, the application process may query a timer process for time information or request screen display information from an alignment process. Communication between these processes can be performed via inter-process communication (IPC).

[0062] To ensure rapid application execution, application processes can be boosted (e.g., assigned a higher priority to secure resources) to prevent or reduce delays. However, service processes (e.g., timers or sorting processes) that communicate with application processes are not boosted, which can lead to delays. Specifically, because service processes have a lower priority than application processes, they may not receive sufficient (or efficient) CPU resources, preventing them from performing tasks related to the service process requested by the application. If the service process's tasks are not performed, the application process may also be delayed (e.g., waiting for the service process's tasks to complete). This situation is referred to as priority inversion. Priority inversion refers to a situation where the operation of a higher-priority process (e.g., the application process) is delayed by a lower-priority process (e.g., the service process). In other words, even though the application process has a higher priority than the service process, the application process may not be processed until the service process's tasks are completed due to insufficient CPU resources, resulting in delays. An example of priority inversion occurring between service processes is described in detail with reference to Figure 3.

[0063] FIG. 3 is a diagram illustrating an example in which priority inversion occurs between service processes according to one embodiment.

[0064] Referring to FIG. 3, the first process (302), the second process (304), and the third process (306) may be service processes for executing an application. For example, the application may be executed when the first process (302), the second process (304), and the third process (306) are processed and the application process (308) is launched.

[0065] Communication may be performed between any two of the first process (302), the second process (304), the third process (306), and the application process (308). For example, the first process (302) and the second process (304) may perform inter-process communication (or IPC). The first process (302) with a higher priority may not be able to execute in a waiting state until the second process (304) with a lower priority occupies (e.g., allocates) CPU resources and responds to the IPC. For example, the first process (302) may not be able to execute during the waiting time (e.g., IPC wait) from the time it transmits an IPC request signal to the second process (304) to the time it receives an IPC response signal from the second process (304). That is, a priority inversion may occur between the first process (302) and the second process (304), and the execution of the first process (302) may be delayed. Delaying the execution of the first process (302) may result in delays in the execution of the third process (306) and the creation of the application process (308), which are subsequently performed, and may consequently delay the execution of the application. Therefore, a resource management technique capable of preventing and / or reducing priority inversion may be required.

[0066] Electronic devices can utilize various CPU scheduling methods to manage CPU resources more efficiently. For example, the Linux kernel can utilize real-time scheduling (hereinafter referred to as "Real-Time Scheduling") and the Completely Fair Scheduler (CFS) scheduling method.

[0067] Real-Time scheduling is based on a real-time scheduler and can preempt CPU resources based on high priorities. CFS scheduling is based on the CFS scheduler and can be used to fairly allocate CPU resources. CFS scheduling can be used to allocate CPU resources to processes within a control group based on CPU resource usage determined for each control group.

[0068] [Table 1] below is a table showing scheduling policies that can be applied to the Real-Time scheduling method or the CFS scheduling method.

[0069]

[0070] Referring to [Table 1], scheduling policies can include the SCHED_FIFO policy, the SCHED_RR policy, and the SCHED_OTHER (SCHED_NORMAL) policy.

[0071] The SCHED_FIFO and SCHED_RR policies are policies for real-time tasks and can be classified as Real-Time classes that can be used for Real-Time scheduling. The SCHED_OTHER (SCHED_NORMAL) policy is for tasks with lower priorities than Real-Time tasks and can be classified as Normal classes that can be used for CFS scheduling.

[0072] The SCHED_FIFO and SCHED_RR policies can be assigned higher priorities than the SCHED_OTHER (SCHED_NORMAL) policy. Priority can refer to resource allocation priority or scheduling priority. Regarding priorities in [Table 1], a smaller number indicates (or may indicate) a higher priority. For example, 1 can indicate the highest priority, while 139 can indicate the lowest priority.

[0073] The SCHED_FIFO policy can be used to allocate CPU resources to the process that is ready first, based on the "First Come First Served (or First In First Out)" method. The SCHED_RR and SCHED_OTHER (SCHED_NORMAL) policies can be used to allocate CPU resources to processes in order, based on the "Round Robin" method. When the SCHED_RR and SCHED_OTHER (SCHED_NORMAL) policies are used, each process can use CPU resources for the allocated time and then yield CPU resources to the next process.

[0074] As shown in [Table 1], the SCHED_FIFO or SCHED_RR policies can be policies corresponding to relatively high priorities and can be policies that utilize the Real-Time scheduling method. The SCHED_OTHER (SCHED_NORMAL) policy can be policies corresponding to relatively low priorities and can be policies that utilize the CFS scheduling method.

[0075] FIG. 4 is a graph illustrating context switch latency that may occur depending on a scheduling method according to one embodiment.

[0076] Referring to FIG. 4, the context switch delay that may occur when the CFS scheduling method (410) is used may be longer than the context switch delay that may occur when the Real-Time scheduling method (420) is used.

[0077] Context switch latency can refer to the time delay that occurs during a process switch, for example. For example, context switch latency can represent the time it takes for a process in a waiting state (or mode) to wake up.

[0078] For example, when the CFS scheduling method (410) is used, the actual process wake-up (404) may occur 57.47 us after the required wake-up time (402). Therefore, when the CFS scheduling method (410) is used, a context switch delay of 57.47 us may occur.

[0079] For example, when the Real-Time scheduling method (420) is used, the actual process wake-up (406) may occur 7.91 us after the required wake-up time (402). Therefore, when the Real-Time scheduling method (420) is used, a context switch delay of 7.91 us may occur.

[0080] The CFS scheduling scheme (410) can prevent or reduce CPU starvation by ensuring that processes use CPU resources fairly (e.g., efficiently or better) . CPU starvation can indicate a situation where a specific process occupies CPU resources, preventing other processes from using the resources. The CFS scheduling scheme (410) has a relatively long context switch delay and does not guarantee that CPU resources are always available, so it can be used for tasks that require long periods of time to perform.

[0081] The Real-Time scheduling method (420) can guarantee CPU resources until the process transitions to a sleep state on its own, with a relatively short context switch delay. Therefore, the Real-Time scheduling method (420) can be used for real-time tasks. The Real-Time scheduling method (420) can cause a CPU starvation state in which other processes cannot access CPU resources (e.g., the CPU cannot be used), and therefore, it can be used for tasks that need to be performed for a short period of time (e.g., a short time).

[0082] The CFS scheduling method (410) and the Real-Time scheduling method (420) can be used together in a single OS. For example, by allocating resources to processes associated with media (e.g., video or audio) playback based on the Real-Time scheduling method (420), CPU usage can be guaranteed and interruptions in media playback can be prevented or reduced. Resources can be allocated to processes associated with applications running in the foreground based on the CFS scheduling method (410). For example, by allocating the process to a control group that can utilize more CPU resources than other processes, the application can be run smoothly.

[0083] FIG. 5 is a signal flow diagram illustrating a process of executing an application in an electronic device according to one embodiment.

[0084] Referring to FIG. 5, a first application selected by a user from among one or more applications that can be executed on an electronic device may be associated with one or more services. For example, the first application may be associated with first to fourth services. The first to fourth services may correspond to process A (520), process B (522), process C (524), or process D (526), ​​respectively. Communication may be performed between any two of process A (520), process B (522), process C (524), or process D (526). According to one example, the first application may be executed in response to a user input through sequential operations of process A (520), process B (522), process C (524), process D (526), ​​and application process (528). For example, the first application may be executed through the following operations.

[0085] In operation 502, process A (520) may receive user input. In one example, process A (520) may be associated with a portal application or a home application that enables selection of a first application. In one example, the user input may be an input requesting or instructing the electronic device to execute the first application. In one example, the user input may be a signal received by the electronic device from at least one external electronic device. For example, if the electronic device is a TV, the user input may be a signal corresponding to a key input of a remote control selected by the user, or a signal corresponding to a touch input of a user interface (UI) displayed on the screen of the mobile terminal.

[0086] In operation 504, process A (520) may, in response to receiving user input, transmit a first request signal to process B (522) requesting execution of a first application. In one example, process B (522) may, in response to the first request signal, identify information associated with the first application (e.g., application execution information). For example, process B (522) may identify the first application as a web-based application.

[0087] At operation 506, process B (522) may transmit a second request signal including information associated with the first application (e.g., application execution information) to process C (524). In one example, process C (524) may perform an operation to execute the first application in a web-based manner in response to the second request signal.

[0088] At operation 508, when the execution of the operation is completed, process C (524) may transmit a third request signal to process D (526) requesting execution of the first application.

[0089] At operation 510, process D (526) may, in response to the third request signal, transmit a signal to the application process (528) indicating execution or initiation of the first application.

[0090] At operation 512, an application process (528) may be started in response to a third request signal. The start of the application process (528) may be performed based on a process fork operation or a candidate launch operation.

[0091] In one example, the process fork operation may include creating an application process (528) associated with a first application, assigning a process identifier (PID) to the created application process (528), and creating one or more tasks (or threads). The one or more tasks may include multiple tasks having a parent-child relationship. In one example, in response to the process fork operation being performed, a creation event may occur in operation 514. The creation event is an event indicating the creation of the application process (528), and may include a process fork event. The occurrence time of the creation event may be identified as the start time or the creation time of the application process (528).

[0092] In one example, the candidate initiation action may include an action of resuming (or executing or activating) the application process (528), if the application process (528) was previously forked but stopped. In one example, in response to the candidate initiation action being performed, a resume event may be generated at action 516. The point in time at which the resume event occurs may be identified as the start point of the application process (528).

[0093] In one example, in response to an occurrence of a create event or a resume event, a first application may be executed, and at operation 518, a screen associated with the first application may be displayed on the electronic device.

[0094] In one example, a nested boosting operation may be performed to quickly launch an application (e.g., the first application of FIG. 5) after a cold boot of an electronic device. In one example, the nested boosting operation may include an operation utilizing at least two scheduling schemes. The at least two scheduling schemes may include, but are not limited to, a Real-Time scheduling scheme and a CFS scheduling scheme.

[0095] For convenience of explanation, the Real-Time scheduling method will be referred to as the "RT policy," and the CFS scheduling method will be referred to as the "Cgroup policy." Furthermore, both the RT policy and the Cgroup policy are described as being included in the scheduling policy, which represents the CPU scheduling method. The RT policy may correspond to a higher priority than the Cgroup policy, and the Cgroup policy may correspond to a lower priority than the RT policy. Priority may also be referred to as scheduling priority.

[0096] In electronic devices, most applications run quickly during idle periods when the CPU is in a stable state. However, during cold boot periods when the CPU is busy, applications may run slowly. Considering this, electronic devices can perform redundant boosting operations. For example, when running applications during idle periods, the device can utilize an RT policy that maximizes CPU resource utilization. However, when the application execution time has elapsed, the device can utilize a Cgroup policy, which offers higher stability than the RT policy. Therefore, performing redundant boosting operations can secure the necessary CPU resources.

[0097] FIG. 6 is an exemplary system architecture diagram for CPU resource management of an electronic device according to one embodiment.

[0098] Referring to FIG. 6, a system for CPU resource management of an electronic device may include an application (602), a platform (604), and a kernel (606).

[0099] The application (602) may be referred to as an APP or may be associated with a service. The application (602) may include a software program that is executed by the user's selection. In one example, the application (602) may be executed by the user's selection using at least one external electronic device or a remote control device (e.g., a remote control). In one example, the application (602) is executed based on the OS and may or may not be displayed on the screen of the electronic device. The application (602) may provide various services, such as media playback. In one example, the application (602) may include a home application (612) that is displayed on the screen of the electronic device after a cold boot. In one example, the home application (612) may be an application that provides a UI for at least one of selecting an application to execute, searching a website, selecting a broadcast channel, or connecting to an external electronic device. In one example, an application (e.g., the first application of FIG. 5) selected by the user may be identified based on an event provided by the home application (612).

[0100] The platform (604) may be associated with an operating system (OS) and may provide an environment for executing applications (602). The platform (604) may access hardware through the kernel (606) and perform control group allocation, control group change or movement, CPU resource allocation or management, or process management operations associated with services. In one example, the platform (604) may include a web application service (WAS) (622), an application management daemon (AMD) (624), a boost daemon (or boost module) (626), and a service process (or process) (628).

[0101] WAS (622) can perform operations to provide web-based application services. AMD (624) can manage the execution and life cycle of the application (602).

[0102] The boost daemon (626) may control scheduling policies based on events associated with processes received from the kernel (606), or perform CPU scheduling or CPU resource management. In one example, the boost daemon (626) may include an App Status Listener (630), an Inheritance Booster (632), a Service Booster (634), a Netlink Handler (636), and a Booster Manager (638).

[0103] The app state listener (630) can receive events associated with the life cycle of the application (602), such as application launch events.

[0104] The inheritance booster (632) can perform operations for priority inheritance between processes with different priorities. For example, the inheritance booster (632) can request the booster manager (638) to set (or change) a scheduling policy for a lower priority process so that it inherits the priority of a higher priority process.

[0105] The service booster (634) can manage the CPU resource allocation of the service process (628).

[0106] The netlink handler (636) can receive events associated with the life cycle of a process (e.g., a process fork event, a process execute event, or a process exit event) from the netlink (642) of the kernel (606).

[0107] The booster manager (638) can set scheduling policies, assign control groups, determine resource allocation ratios, or set (or change) CPU resource allocation priorities. For example, in response to a request from the inheritance booster (632), the booster manager (638) can set or change the scheduling policy for a lower priority process so that it inherits the priority of a higher priority process.

[0108] The service process (628) may be a process that operates in the background without a UI and may provide functions necessary for the operation of a UI application. For example, the service process (628) may include process B (522), process C (524), and process D (526) corresponding to the second to fourth services associated with the first application of FIG. 5 . In one example, status information of an application process (e.g., application process (528) of FIG. 5 ) may be identified based on the service process (628). The status information of the application process may include information indicating, for example, one of create, resume, focus, pause, or exit.

[0109] The kernel (606) can manage hardware and provide services required for the platform (604). The kernel (606) can include a Netlink (642), a Cgroup (644), and a RealTime Scheduling (646) unit.

[0110] Netlink (642) can provide events associated with the lifecycle of a service process (628), such as a process fork event, a process execution event, a process resume event, or a process termination event. Cgroup (644) can provide a CPU resource allocation function. In one example, Cgroup (644) can perform a CPU resource allocation function for each of one or more configured control groups. A real-time scheduling unit (646) can perform real-time scheduling to preempt CPU resources.

[0111] In the system illustrated in FIG. 6, priority inheritance operations can be performed to prevent priority inversion between processes. For example, priority inheritance operations can be performed as described and illustrated in detail below with respect to FIG. 7.

[0112] FIG. 7 is a diagram illustrating an exemplary priority inheritance operation between processes performed in an electronic device according to one embodiment.

[0113] Referring to FIG. 7, priority inheritance behavior can be applied to communication between processes executing at a given point in time. For example, the processes may be associated with an application to be executed and may be processes performing IPC. For example, if the application to be executed is the first application of FIG. 5, the processes may be Process B (522) and Process C (524) of FIG. 5, or Process C (524) and Process D (526) of FIG. 5.

[0114] For example, a first process (720) (e.g., process B (522) or process C (524) in FIG. 5) which is a communication request process among the processes may be referred to as a Caller or an IPC sending process. For example, a second process (740) (e.g., process C (524) or process D (526) in FIG. 5) which is a communication response process among the processes may be referred to as a Callee or an IPC receiving process. Hereinafter, the first process (720) will be referred to as a Caller and the second process (740) will be referred to as a Callee, but the terms referring to each of the first process (720) and the second process (740) are not limited thereto and may be variously changed.

[0115] For example, Caller (720) may have a relatively higher scheduling priority than Callee (740), and Callee (740) may have a relatively lower scheduling priority than Caller (720). Callee (740) may be pre-registered as a priority inheritance target process. For example, Callee (740) may request Boost Daemon (626) to register Callee (740) as a priority inheritance target process using a registration-related API (application programming interface). Callee (740) may call the set API when it is called a threshold number of times or more to execute one or more applications after performing a cold boot. Boost Daemon (626) may register Callee (740) as a priority inheritance target process in response to Callee's request.

[0116] In operation 701, Caller (720) can call the first library (hereinafter referred to as 'libcallee') (701) corresponding to Callee (740).

[0117] In operation 702, if Callee (740) is previously registered as a priority inheritance target process, the first library may request boosting of Callee (740). In one example, boosting may include an operation of changing a scheduling policy to have a high scheduling priority, or an operation of inheriting a high scheduling priority. In one example, the boosting request may be provided to the boost daemon (626) via the second library (hereinafter referred to as 'libboost') (703). In one example, the boosting request may be provided to the boost daemon (626) if Callee (740) is registered as a priority inheritance target process, and the scheduling priority of Callee (740) is lower than the scheduling priority of Caller (720). In one example, the boosting request may include information about the scheduling priority of Caller (720), or information about the scheduling policy applied to Caller (720).

[0118] The inheritance booster (632) of the boost daemon (626) can receive a boosting request provided from the Caller (720). In response to receiving the boosting request, the inheritance booster (632) can request the booster manager (638) to perform an operation for boosting the Callee (740) (e.g., inheritance of the scheduling priority or scheduling policy of the Caller (720)).

[0119] The booster manager (638) may, in response to a request from the inheritance booster (632), set or change the scheduling policy of the callee (740) so that the scheduling priority of the caller (720) is inherited by the callee (740) (or so that the scheduling policy applied to the caller (720) is inherited by the callee (740). For example, if a cgroup policy is set (e.g., configured or changed) for the callee (740), the booster manager (638) may disable the cgroup policy and set (e.g., configured or changed) an RT policy for the callee (740) so that the callee (740) has the same scheduling priority as the caller (720). In one example, the RT policy may be a scheduling policy applied to the caller (720).

[0120] In operation 704, the booster manager (638) may provide the kernel (606) with information about the scheduling policy set for the Callee (740). In the kernel (606), resource allocation may be performed by the Cgroup (644) or the real-time scheduling unit (646) based on the scheduling policy set for the Callee (740). For example, if the set scheduling policy is an RT policy, the real-time scheduling unit (646) may preemptively allocate CPU resources to the Callee (740).

[0121] At operation 706, Caller (720) may send an IPC request to Callee (740).

[0122] At operation 708, Callee (740) can process IPC requests with a high scheduling priority based on boosting.

[0123] At operation 710, Callee (740) may send an IPC response to Caller (720) in response to processing the IPC request.

[0124] At operation 712, the Caller (720) may request boosting release from the Callee (740). In one example, the boosting release request may be provided to the Boost Daemon (626) via libboost (703).

[0125] The inheritance booster (632) of the boost daemon (626) can receive a boosting release request provided by the Caller (720). In response to receiving the boosting release request, the inheritance booster (632) can request the booster manager (638) to perform an action for boosting release of the Callee (740) (e.g., releasing inheritance of the scheduling priority or scheduling policy of the Caller (720)).

[0126] The booster manager (638) may, in response to a request from the inheritance booster (632), determine whether a timeout event associated with a priority inheritance operation has occurred. In one example, the timeout event may occur a specific amount of time after the priority inheritance is performed.

[0127] In response to a timeout event occurring, the booster manager (638) may change (or update) the scheduling policy of the callee (740) so that the scheduling priority inherited by the callee (740) is released (or the scheduling policy inherited by the caller (720) is released). For example, the booster manager (638) may release the RT policy set for the callee (740) and set a Cgroup policy corresponding to a lower scheduling priority for the callee (740). In one example, the Cgroup policy may be a scheduling policy previously set for the callee (740).

[0128] In operation 714, the booster manager (638) may provide information about the configured scheduling policy to the kernel (606). In the kernel (606), resource allocation may be performed by the Cgroup (644) or the real-time scheduling unit (646) based on the scheduling policy configured for the Callee (740). For example, if the scheduling policy configured for the Callee (740) is a Cgroup policy, the kernel (606) may allocate CPU resources to the Callee (740) based on a resource allocation ratio corresponding to a control group including the Callee (740).

[0129] For example, overlapping boosting operations utilizing RT policies and Cgroup policies can be performed during application process creation or in conjunction with priority inheritance operations. These operations are described in detail below with reference to FIGS. 8 and 9.

[0130] FIG. 8 is a graph illustrating an example in which a duplicate boosting operation is performed according to one embodiment.

[0131] Referring to FIG. 8, the electronic device may perform a duplicate boosting operation in response to the creation of an application process (e.g., application process (528) of FIG. 5 ). In one example, the electronic device may identify the creation of an application process based on the occurrence of a process fork event associated with the application.

[0132] The electronic device may first apply the RT policy (602) corresponding to a relatively high scheduling priority among the RT policy (802) and the Cgroup policy (804) that can be used for the duplicate boosting operation to the application process. For example, the RT policy (802) may be applied to the application process from the time point T1 (806) when the application process is created to the time point T2 (808) when a set period of time has elapsed. While the RT policy (802) is being applied, the Cgroup policy (804) may not be applied to the application process.

[0133] The electronic device can switch (810) the scheduling policy to be applied to the application process at time T2 (808) when the application of the RT policy (802) is completed. For example, the electronic device can switch (810) the scheduling policy from the RT policy (802) to the Cgroup policy (804) at time T2 (808). That is, the electronic device can apply the Cgroup policy (804), which has higher stability than the RT policy (802), to the application process from time T2 (808). The Cgroup policy (804) can be applied from time T2 (808) until the application process is terminated, or from time T2 (608) until time T3 (812) when a set amount of time has elapsed.

[0134] FIG. 9 is a graph illustrating another example in which a duplicate boosting operation is performed according to one embodiment.

[0135] Referring to FIG. 9, an electronic device may perform a duplicate boosting operation for a second process (e.g., Callee (740) of FIG. 7) that can communicate with a first process (e.g., Caller (720) of FIG. 7) having a relatively high scheduling priority. The second process may be a process having a lower scheduling priority than the first process.

[0136] For example, the electronic device may apply the Cgroup policy (804) to the second process from time T1 (906) when the second process is created to time T2 (908). For example, the second process may inherit the scheduling priority of the first process at time T2 (908). The electronic device may switch (910) the scheduling policy to be applied to the second process at time T2 (908). For example, the electronic device may switch (910) the scheduling policy from the Cgroup policy (804) to the RT policy (802) at time T2 (908).

[0137] The electronic device may apply the RT policy (802) to the second process from time T2 (908) to time T3 (912), which is the first time elapsed. While the RT policy (802) is being applied, the Cgroup policy (804) may not be applied to the second process.

[0138] The electronic device may switch (914) the scheduling policy from the RT policy (802) to the Cgroup policy (804) at time T3 (912) when the priority inheritance operation is completed. The Cgroup policy (804) may be applied from time T3 (912) until the second process terminates, or from time T3 (912) until time T4 (916) when the second time has elapsed. In one example, the first time and the second time may be preset times and may be the same or different.

[0139] FIG. 10 is a flowchart illustrating a resource management operation of an electronic device according to one embodiment.

[0140] Referring to FIG. 10, in operation 1002, in response to a request for execution of an application, at least one service for execution of the application can be identified.

[0141] In operation 1004, the electronic device may determine a first scheduling policy and a second scheduling policy to be applied to at least one process associated with at least one service. In one example, the at least one process may be at least one process that performs tasks associated with the execution of an application (e.g., an application execution permission check process or a security-related process). In one example, the at least one process may be referred to as an assisting process and may affect the startup performance of the application when its operation is delayed. In one example, the at least one process may be used for the execution of multiple applications. In one example, the first scheduling policy and the second scheduling policy may be used for overlapping boosting operations for at least one process.

[0142] In operation 1006, the electronic device can apply a first scheduling policy corresponding to a higher scheduling priority among the first scheduling policy and the second scheduling policy to at least one process.

[0143] In operation 1008, in response to the creation of an application process executing an application, the electronic device may release the first scheduling policy and apply the second scheduling policy to at least one process. In one example, the creation of the application process may be identified based on the occurrence of a creation event (e.g., a process fork event) indicating the creation of the application process.

[0144] For example, if at least one process is utilized by multiple applications, information for the overlapping boosting operation of at least one process (e.g., the first scheduling policy and the second scheduling policy) can be managed as common configuration information for the multiple applications, while information specific to each application can be managed as separate configuration information. The separate configuration information can be provided using a file or API that is distinct from the common configuration information.

[0145] According to an example, the first scheduling policy may include a policy (e.g., an RT policy) that preferentially allocates a first resource to at least one process. According to an example, the second scheduling policy may include a policy (e.g., a Cgroup policy) that allocates a second resource to at least one process based on a set resource allocation ratio. The set resource allocation ratio may correspond to at least one control group that includes at least one process among the plurality of control groups.

[0146] FIG. 11 is a flowchart illustrating a duplicate boosting operation applied to an application process according to one embodiment.

[0147] In operation 1102, the electronic device may apply a first scheduling policy (e.g., an RT policy) to the application process in response to the creation of the application process. In one example, operation 1102 may be performed subsequent to operation 1008 of FIG. 10 or may be performed in parallel with operation 1008.

[0148] In operation 1104, the electronic device can determine whether a set time has elapsed since the first scheduling policy was applied to the application process. For example, the set time may be N seconds (e.g., 5 seconds) if the application process is for the first execution of the application, or M seconds (e.g., 2 seconds) if the application process is for the restart of the application. Here, N may represent a time (or period) equal to or greater than M. The set time may be set as a timeout value in a predetermined format (e.g., json (JavaScript object notation) format). The set time may be included in a specific file (e.g., a manifest file) and set (e.g., configured or programmed) identically or differently for each application.

[0149] In operation 1106, the electronic device may release the first scheduling policy applied to the application process and apply a second scheduling policy (e.g., a Cgroup policy) to the application process in response to a set amount of time having elapsed (or expired) from the time the first scheduling policy was applied to the application process.

[0150] FIG. 12 is a flowchart illustrating a priority inheritance operation between a first process and a second process according to one embodiment.

[0151] Referring to FIG. 12, in operation 1202, the electronic device may identify a first process, which is a communication request process among the processes, and a second process, which is a communication response process among the processes, in response to a need for communication between processes at a given point in time. In one example, the first process may correspond to an application process (e.g., application process (528) of FIG. 5), and the second process may correspond to at least one process associated with at least one service (e.g., process B (522), process C (524), and process D (526) of FIG. 5).

[0152] In operation 1204, the electronic device may compare a first scheduling priority of a first process and a second scheduling priority of a second process.

[0153] At operation 1206, the electronic device may determine whether the first scheduling priority is higher than the second scheduling priority.

[0154] In operation 1208, in response to the first scheduling priority being higher than the second scheduling priority, the electronic device may inherit the first scheduling priority to the second process. In one example, the second process may be registered as a priority inheritance target process. In one example, to inherit the first scheduling priority to the second process, the electronic device may apply a scheduling policy (e.g., an RT policy) applied to the first process to the second process.

[0155] FIG. 13 is a flowchart illustrating a priority inheritance release operation between a first process and a second process according to one embodiment.

[0156] Referring to FIG. 13, in operation 1302, the electronic device may determine whether a set time has elapsed (or expired) from the time the first scheduling priority is inherited by the second process. In one example, operation 1302 may be performed subsequent to operation 1208 of FIG. 12.

[0157] In operation 1304, the electronic device may perform operation 1302 again in response to a set amount of time not having elapsed since the first scheduling priority was inherited by the second process (e.g., time remaining).

[0158] In operation 1304, the electronic device may, in response to a set amount of time having elapsed since the first scheduling priority was inherited by the second process, release the inheritance of the first scheduling priority to the second process in operation 1306.

[0159] FIG. 14 is a flowchart illustrating priority inheritance operations between multiple first processes and second processes according to one embodiment.

[0160] Referring to FIG. 14, in operation 1402, the electronic device can identify a plurality of first processes, which are communication requesting processes among the processes, and a second process, which is a communication responding process among the processes, in response to a need for communication between the processes at a given point in time.

[0161] At operation 1404, the electronic device can identify a third scheduling priority corresponding to a highest priority among the scheduling priorities of each of the plurality of first processes.

[0162] At operation 1406, the electronic device may compare the third scheduling priority with the second scheduling priority of the second process.

[0163] At operation 1408, the electronic device may, in response to the third scheduling priority being higher than the second scheduling priority, inherit the third scheduling priority to the second process at operation 1410.

[0164] At operation 1408, the electronic device may terminate all operations in response to the third scheduling priority not being higher than the second scheduling priority.

[0165] FIG. 15 is an exemplary block diagram of an electronic device according to one embodiment.

[0166] Referring to FIG. 15, an electronic device (1500) may include a display (1502), a memory (1504), and a processor (1506) (e.g., including a processing circuit). In one example, the electronic device (1500) may include additional components (e.g., a first communication unit (e.g., including a communication circuit) for communicating with an external electronic device or a second communication unit (e.g., including a communication circuit) for communicating with a remote control device) in addition to the illustrated components, or may omit at least one of the illustrated components.

[0167] According to one example, the display (1502) can perform various display operations according to the function of the electronic device (1500). For example, the display (1502) can display at least one of various service information, media information, text information, or broadcast information according to the execution of an application.

[0168] According to one example, the memory (1504) can store various information or data associated with the operation of the electronic device (1500) and can store at least one program.

[0169] According to one example, the processor (1506) includes various processing circuitry, is electrically connected to the display (1502) and the memory (1504), respectively, and can execute at least one instruction of a program stored in the memory (1504). There may be one or more processors (1506) and can perform the operations of the electronic device (1500) described above. For example, the processor (1506) can perform the following operations. The processor (1506) according to one embodiment of the present disclosure can include various processing circuitry and / or multiple processors. For example, as used in this disclosure, including the claims, the term “processor” can include various processing circuitry including at least one processor, wherein one or more of the at least one processor can be configured to perform various functions described in the present disclosure in an individually and / or collectively distributed manner. As used herein, when "processor," "at least one processor," and "one or more processors" are described as being configured to perform multiple functions, these terms encompass, for example, but are not limited to, situations where one processor performs some of the recited functions, other processor(s) perform other parts of the recited functions, and also situations where a single processor can perform all of the recited functions. Additionally, the at least one processor may comprise a combination of processors that perform the various recited / disclosed functions, for example, in a distributed manner. At least one processor may execute program instructions to achieve or perform the various functions.

[0170] In one example, the processor (1506) may, in response to a request for execution of an application, identify at least one service associated with the application. The processor (1506) may determine a first scheduling policy (e.g., an RT policy) and a second scheduling policy (e.g., a Cgroup policy) to be applied to at least one process associated with the at least one service. The processor (1506) may apply a first scheduling policy corresponding to a higher scheduling priority among the first scheduling policy and the second scheduling policy to the at least one process. In response to the creation of an application process for executing the application, the processor (1506) may release the first scheduling policy and apply the second scheduling policy to the at least one process.

[0171] In one example, the processor (1506) may apply a first scheduling policy to the application process in response to the creation of the application process. In response to a set amount of time elapsed since the first scheduling policy was applied to the application process, the processor (1506) may release the first scheduling policy applied to the application process and apply a second scheduling policy to the application process.

[0172] In one example, in response to a need for communication between processes at a given point in time, the processor (1506) may identify a first process, which is a communication requesting process among the processes, and a second process, which is a communication responding process among the processes. The processor (1506) may compare a first scheduling priority of the first process with a second scheduling priority of the second process, and in response to the first scheduling priority being higher than the second scheduling priority, may inherit the first scheduling priority to the second process.

[0173] In one example, the first process may correspond to an application process, and the second process may correspond to at least one of the processes.

[0174] In one example, the processor (1506) may determine whether a set amount of time has elapsed or expired since the time at which the first scheduling priority was inherited by the second process, and in response to the elapsed amount of time, may release the inheritance of the first scheduling priority for the second process.

[0175] For example, the first scheduling priority may be determined based on the first scheduling policy to preferentially allocate the first resource to the first process. For example, the second scheduling priority may be determined based on the second scheduling policy to preferentially allocate the second resource corresponding to the set resource allocation ratio to the second process.

[0176] For example, a second process may be registered as a priority inheritance target process.

[0177] In one example, in response to the first process being identified as multiple, the processor (1506) may identify a third scheduling priority corresponding to a highest priority among the scheduling priorities of each of the first processes, and compare the third scheduling priority with the second scheduling priority of the second process. In response to the third scheduling priority being higher than the second scheduling priority, the processor (1506) may inherit the third scheduling priority to the second process.

[0178] Figure 16 is a graph showing the execution performance of application A according to one embodiment.

[0179] In the graph of Figure 16, the horizontal axis represents the app execution time (time(sec)), and the vertical axis represents the number of tests (count). App execution time can represent the time from the time when user input related to application execution is received to the time when the application is executed.

[0180] In Fig. 16, the dotted line graph represents the execution performance of application A when the method according to the various embodiments described above (hereinafter referred to as the “disclosed method”) is applied, and the solid line graph represents the execution performance of conventional application A.

[0181] Referring to FIG. 16, the results of repeated testing by executing application A 1000 times after a cold boot on an electronic device show that the average app execution time of the disclosed method is reduced from 22 seconds to 12 seconds, improving the average execution performance, and the variance is also improved from 3.28 to 1.48.

[0182] Figure 17 is a graph showing the execution performance of application B according to one embodiment.

[0183] The graph in Figure 17 shows the execution performance of application B, which is different from application A. When the disclosed method is applied to application B, its execution performance can be improved, similar to application A.

[0184] Referring to FIG. 17, the results of repeated testing by executing application B 1,000 times after a cold boot on an electronic device show that the average app execution time of the disclosed method is reduced from 22 seconds to 9.7 seconds, improving average execution performance, and the variance is also improved from 3.17 to 1.55. Consequently, the execution performance of an application after a cold boot can be improved when the disclosed method is utilized.

[0185] Figure 18 is a graph illustrating boot performance and application execution performance according to one embodiment.

[0186] In the graph of Figure 18, the horizontal axis represents applications (e.g., applications A to E), and the vertical axis represents the sum of the cold boot time and the app execution time. Cold boot time can represent the time from when power is applied to the electronic device until booting is complete and the screen is first displayed. Cold boot time can be related to boot performance. App execution time can represent the time until the application is launched after a cold boot and can be related to application execution performance.

[0187] Figure 18(a) shows the sum of the conventional cold boot time and the app execution time for each of applications A to E. Figure 18(b) shows the sum of the cold boot time and the app execution time of the disclosed method for each of applications A to E. Comparing Figure 18(a) and Figure 18(b), it can be seen that the booting performance and application execution performance are better when the disclosed method is followed compared to the conventional method.

[0188] 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, home appliances, or other devices. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

[0189] 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 the corresponding component from other corresponding components and do not limit the corresponding components in any other respect (e.g., importance or order). When a (e.g., first) component is referred to as "coupled" or "connected" to another (e.g., second) component, with or without the terms "functionally" or "communicatively," the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component. The term "module" as used in various embodiments of this document can include a unit implemented in hardware, software, or firmware, or any combination thereof, and can be used interchangeably with terms such as logic, logic block, component, or circuit. A module can be an integral component or the smallest unit or part of such a component that performs one or more functions.For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0190] 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.

[0191] While the present disclosure has been illustrated and described with reference to various exemplary embodiments, it is to be understood that the various exemplary embodiments are illustrative and not limiting. Those skilled in the art will further appreciate that various modifications are possible within the scope of the present disclosure, including the appended claims and their equivalents. It is also to be understood that any embodiment(s) described in the present disclosure may be used in conjunction with other embodiments described in the present disclosure.

Claims

1. In electronic devices, memory for storing at least one program; and At least one processor electrically connected to said memory, comprising a processing circuit and configured to execute at least one instruction of a program stored in said memory, At least one processor, individually and / or collectively: In response to a request for execution of an application, identifying at least one service associated with said application, Determine a first scheduling policy and a second scheduling policy to be applied to at least one process associated with at least one service, Applying the first scheduling policy corresponding to a higher scheduling priority among the first scheduling policy and the second scheduling policy to at least one process, An electronic device, in response to the creation of an application process executing the application, releasing the first scheduling policy and applying the second scheduling policy to the at least one process.

2. In paragraph 1, The above first scheduling policy includes a policy for preferentially allocating a first resource to at least one process, The second scheduling policy includes a policy for allocating a second resource to at least one process based on a set resource allocation ratio, An electronic device, wherein the above-set resource allocation ratio corresponds to at least one control group including at least one process among a plurality of control groups.

3. In paragraph 1, At least one processor, individually and / or collectively: In response to the creation of the above application process, applying the first scheduling policy to the above application process, An electronic device, in response to a set time elapsed from the time at which the first scheduling policy was applied to the application process, releasing the first scheduling policy applied to the application process and applying the second scheduling policy to the application process.

4. In paragraph 1, At least one processor, individually and / or collectively: In response to a need for communication between processes at a particular point in time, a first process comprising a communication request process and a second process comprising a communication response process are identified, Compare the first scheduling priority of the first process and the second scheduling priority of the second process, An electronic device, wherein in response to the first scheduling priority being higher than the second scheduling priority, the first scheduling priority is inherited by the second process.

5. In paragraph 4, The above first process corresponds to the above application process, An electronic device, wherein the second process corresponds to at least one of the above processes.

6. In paragraph 4, At least one processor, individually and / or collectively: Determine whether the set time has elapsed since the first scheduling priority was inherited by the second process, An electronic device, responsive to the lapse of said set time, that releases inheritance of said first scheduling priority to said second process.

7. In paragraph 4, The above first scheduling priority is determined based on the above first scheduling policy to preferentially allocate the first resource to the first process, An electronic device, wherein the second scheduling priority is determined to allocate a second resource corresponding to a set resource allocation ratio to the second process based on the second scheduling policy.

8. In paragraph 4, An electronic device wherein the second process is registered as a priority inheritance target process.

9. In paragraph 4, At least one processor, individually and / or collectively: In response to the first process being identified as being a plurality of, a third scheduling priority corresponding to a highest priority among the scheduling priorities of each of the first processes is identified, Compare the third scheduling priority with the second scheduling priority of the second process, An electronic device, wherein the third scheduling priority is higher than the second scheduling priority, and the third scheduling priority is inherited by the second process.

10. In the method of managing resources of an electronic device, In response to a request for execution of an application, the act of identifying at least one service associated with the application; An operation of determining a first scheduling policy and a second scheduling policy to be applied to at least one process associated with at least one service; An operation of applying the first scheduling policy corresponding to a higher scheduling priority among the first scheduling policy and the second scheduling policy to at least one process; and A method comprising, in response to an application process being created to execute said application, an action of releasing said first scheduling policy and applying said second scheduling policy to said at least one process.

11. In paragraph 10, The above first scheduling policy includes a policy for preferentially allocating a first resource to at least one process, The second scheduling policy includes a policy for allocating a second resource to at least one process based on a set resource allocation ratio, A method wherein the above-set resource allocation ratio corresponds to at least one control group including at least one process among a plurality of control groups.

12. In paragraph 10, In response to the creation of said application process, an operation of applying said first scheduling policy to said application process; and A method further comprising: in response to a set time elapsed from the time at which the first scheduling policy was applied to the application process, releasing the first scheduling policy applied to the application process and applying the second scheduling policy to the application process.

13. In paragraph 10, In response to a need for communication between processes at a particular point in time, an act of identifying a first process comprising a communication requesting process and a second process comprising a communication responding process; An operation of comparing the first scheduling priority of the first process and the second scheduling priority of the second process; and A method further comprising: in response to the first scheduling priority being higher than the second scheduling priority, inheriting the first scheduling priority to the second process.

14. In paragraph 13, An operation for determining whether a set time has elapsed since the time at which the first scheduling priority was inherited by the second process; and A method further comprising: in response to the set time period having elapsed, releasing inheritance of the first scheduling priority for the second process.

15. In paragraph 13, In response to the first process being identified as being plural, an operation of identifying a third scheduling priority corresponding to a highest priority among the scheduling priorities of each of the first processes; An operation of comparing the third scheduling priority with the second scheduling priority of the second process; and A method further comprising: in response to the third scheduling priority being higher than the second scheduling priority, inheriting the third scheduling priority to the second process.

Images