Core selection method, electronic equipment, computer readable storage medium and program product

Abstract

The invention relates to the technical field of electronic equipment, and provides a core selection method, electronic equipment, a computer readable storage medium and a program product, which are applied to the electronic equipment, the electronic equipment comprises a central processing unit, and the core of the central processing unit comprises a middle core and a large core. The method comprises the steps that the electronic equipment determines a load threshold value used by core selection according to frequency limiting values of a middle core and a large core, and then whether a target thread needing to be migrated to the large core for operation exists or not is determined on the basis of thread loads of candidate threads participating in core selection and the determined load threshold value. The frequency limiting value is dynamically set based on the target application and the running state of the electronic equipment, so that the load threshold value determined based on the frequency limiting value can also dynamically change along with the running state of the target application and the running state of the electronic equipment, and adaptive load threshold values can be provided in various application scenes; and good performance power consumption performance under each application scene can be ensured by selecting cores for the candidate threads based on the adaptive load threshold.

Description

Technical Field

[0001] This application relates to the field of electronic equipment technology, and in particular to a core selection method, electronic equipment, computer-readable storage medium, and program product. Background Technology

[0002] Currently, most central processing units (CPUs) in electronic devices such as mobile phones, tablets, and laptops adopt a multi-core heterogeneous architecture. This architecture includes multiple cores, including small cores, medium cores, and large cores. The performance and power consumption of small cores, medium cores, and large cores differ. To balance application performance and power consumption, a traditional strategy is used to schedule application threads to use small cores, medium cores, or large cores. However, this traditional strategy exhibits significant performance differences across different applications and chip platforms, resulting in poor performance and power consumption in some application scenarios. Consequently, it lacks versatility and cannot guarantee good performance and power consumption across all application scenarios. Summary of the Invention

[0003] This application provides a core selection method, an electronic device, a computer-readable storage medium, and a program product. The core selection method is highly versatile and applicable to various application scenarios and chip platforms, thereby ensuring good performance and power consumption in various application scenarios.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0005] Firstly, a core selection method is provided for an electronic device, including a central processing unit (CPU), whose cores include medium-sized cores and large-sized cores. The method includes: launching a target application; obtaining frequency limiting values ​​for the medium-sized and large-sized cores, and determining a load threshold based on the frequency limiting values; wherein the frequency limiting values ​​are dynamically set based on the operating status of the target application and the electronic device; if a target thread exists among candidate threads and is running on the medium-sized core, migrating the target thread from the medium-sized core to the large-sized core; the target thread is determined based on the load threshold and the thread load of the candidate threads; the candidate threads are application threads of the target application.

[0006] In this implementation, because the frequency limit is dynamically set based on the operating state of the target application and electronic device, the frequency limit changes dynamically with the operating state of the target application and electronic device. Therefore, the load threshold determined based on the frequency limit also changes dynamically with the operating state of the target application and electronic device, ensuring an appropriate load threshold for various application scenarios. By making core selection decisions based on the appropriate load threshold, it is possible to dynamically differentiate loads regardless of application scenario or chip platform, thus ensuring good performance and power consumption across all application scenarios. In other words, compared to the traditional method using a fixed load threshold, this implementation method, because the load threshold can change dynamically, is applicable to various application scenarios and chip platforms, has higher versatility, and ensures good performance and power consumption across all application scenarios.

[0007] In one possible implementation of the first aspect, the application thread includes a rendering thread and at least one logical thread. The rendering thread is the application thread in the target application used for frame output, and the logical thread is the application thread that has a wake-up relationship with the rendering thread and is related to frame output. The candidate threads include the rendering thread and the logical thread with the heaviest historical load.

[0008] In this implementation, the application threads that are migrated to the large cores during actual operation are usually the most heavily loaded threads. The rendering threads used for frame output are typically the most heavily loaded application threads in the target application (such as a game). Therefore, selecting the rendering thread and the logic threads associated with it that have historically had the heaviest load as candidate threads for core selection allows for targeted decision-making regarding which candidate threads should run on the large cores. This improves the processing speed of core selection and ensures its accuracy.

[0009] In one possible implementation of the first aspect, the application threads include a rendering thread and at least one logical thread. The rendering thread is the application thread in the target application used for frame output, and the logical thread is an application thread that has a wake-up relationship with the rendering thread and is related to frame output. The core selection method may further include: selecting candidate threads based on the migration priority of the application threads, the candidate threads including the two application threads with the highest migration priority; the migration priority is set based on the historical load of the application threads; wherein, if the target thread is not among the selected candidate threads, candidate threads are reselected based on the migration priority. In another possible implementation, the rendering thread has the highest migration priority.

[0010] In this implementation, if the number of application threads that will migrate to the big core during actual operation is relatively large, then in order to take into account all application threads that may need to run on the big core, a preset migration priority is used to select candidate threads to participate in the core selection. In the case that there is no target thread, a new candidate thread can be selected to participate in the core selection based on the migration priority, thereby ensuring that each application thread has the opportunity to migrate to the big core.

[0011] In one possible implementation of the first aspect, the number of large cores is less than the number of candidate threads, and only one candidate thread runs on a large core. In this implementation, if the number of large cores is greater than the number of candidate threads, it means that the number of large cores is greater than the number of application threads that might run on large cores. In essence, each application thread can occupy a different large core and run stably, so there is no need to migrate to a large core. Therefore, this method is more suitable for situations where the number of large cores is less than the number of candidate threads.

[0012] Meanwhile, candidate threads running on large cores are application threads that require the higher computing power of large cores to ensure good performance. Therefore, if two or more candidate threads run on large cores simultaneously, it may lead to CPU time slice contention, causing application stuttering. To avoid stuttering caused by multiple candidate threads competing for time slices on large cores, only one candidate thread is allowed to run on a large core. For example, if no candidate thread is running on a large core, the target thread can be directly migrated to the large core. However, if a candidate thread is running on a large core, and the target thread is not a candidate thread running on the large core, then to ensure that only one candidate thread runs stably on the large core, while migrating the target thread to the large core, the candidate thread running on the large core can be migrated to a medium core.

[0013] In one possible implementation of the first aspect, obtaining the frequency limiting values ​​of the medium core and the large core includes: obtaining the frequency limiting values ​​of the medium core and the large core after the target application outputs n frames; n is a positive integer greater than or equal to 1; wherein, the thread load corresponding to the candidate thread is the average of the thread loads of n single frames; the n single frame thread loads are thread loads that correspond one-to-one with the n output frames; the single frame thread load is determined after the frame output based on the running time of the candidate thread and the frequency of the core.

[0014] In this implementation, thread load is typically represented by the kernel using the 'util' parameter, which is usually calculated after each frame is output. Therefore, for target applications with highly variable application scenarios, comparing only the thread load of a single frame with a load threshold may result in significant fluctuations, leading to frequent core migrations. Therefore, the thread load of a candidate thread can be the average of the thread loads of n single frames to ensure thread load stability. This means triggering a core selection process only after n frames have been output, preventing fluctuations and frequent core migrations.

[0015] In one possible implementation of the first aspect, the core selection method further includes: if the candidate thread is running on a large core, adjusting the thread load corresponding to the candidate thread using a correction coefficient; wherein the correction coefficient is the ratio of the first load and the second load, the first load is the thread load when the candidate thread is running on a medium core, and the second load is the thread load when the candidate thread is running on a large core; the candidate thread corresponding to the first load and the candidate thread corresponding to the second load are the same.

[0016] In this implementation, the inconsistent maximum computing power of the medium and large cores leads to varying load differences between candidate threads on these cores, which in turn affects the accuracy of target thread selection and thus the core selection decision. Therefore, by adjusting the thread load of candidate threads running on the large core using a correction coefficient, the thread loads of candidate threads on the medium and large cores can be brought to the same level, eliminating this load difference and ensuring the accuracy of core selection.

[0017] In one possible implementation of the first aspect, the core selection method further includes: before correction, if the candidate threads on the large core change, updating the correction coefficients based on the first and second loads corresponding to the changed candidate threads; if the updated correction coefficient is less than a preset first coefficient threshold, using the first coefficient threshold as the correction coefficient; if the updated correction coefficient is greater than a second coefficient threshold, using the second coefficient threshold as the correction coefficient; and the second coefficient threshold is greater than the first coefficient threshold. In this implementation, the correction coefficients are dynamically updated based on the changes in candidate threads on the large core, so as to dynamically adjust the thread load of the candidate threads on the large core and ensure the accuracy of the correction.

[0018] In one possible implementation of the first aspect, the core selection method further includes: determining the load state of the candidate thread based on the load threshold and the thread load of the candidate thread; if the load state is a first state, determining that there is no target thread among the candidate threads; if the load state is a second state, determining that there is a target thread among the candidate threads, and the target thread is the candidate thread corresponding to the largest thread load; the load indicated by the second state is higher than the load indicated by the first state.

[0019] In one possible implementation of the first aspect, the core selection method further includes: if the load state is the third state, determining whether there is a device power consumption gain in migrating the candidate thread corresponding to the largest thread load to run on the large core; the load indicated by the third state is higher than the load indicated by the first state and lower than the load indicated by the second state; if there is a device power consumption gain, the candidate thread corresponding to the largest thread load is taken as the target thread; if there is no device power consumption gain, it is determined that there is no target thread among the candidate threads.

[0020] In this implementation, the load status of candidate threads is used to determine whether there are target threads that need to be migrated to large cores, which can balance application performance and device power consumption, thereby ensuring good performance and power consumption.

[0021] In one possible implementation of the first aspect, the load threshold includes a maximum load threshold and a minimum load threshold; determining the load state of a candidate thread based on the load threshold and the thread load of the candidate thread includes: determining the load state as a first state when the maximum value of the thread load corresponding to the candidate thread is less than the minimum load threshold; determining the load state as a second state when the maximum value of the thread load corresponding to the candidate thread is greater than the maximum load threshold; and determining the load state as a third state when the maximum value of the thread load corresponding to the candidate thread is greater than the minimum load threshold and less than the maximum load threshold.

[0022] In this implementation, the load threshold is distinguished into the highest load threshold and the lowest load threshold. This is compared with the thread load to determine the load status of the candidate thread, which can ensure the accuracy of the load status judgment.

[0023] In one possible implementation of the first aspect, the frequency limit value includes the first maximum frequency limit corresponding to the core, and the load threshold includes the maximum load threshold; the maximum load threshold util1 is determined by the following expression: util1 = smaf_M / fmax_M * ca_M * sa1; where smaf_M is the first maximum frequency limit; fmax_M is the maximum frequency of the core; ca_M is the maximum computing power of the core; and sa1 is a preset constant.

[0024] In one possible implementation of the first aspect, the frequency limiting value also includes a first minimum frequency limit corresponding to the medium core and a second minimum frequency limit corresponding to the large core; the load threshold also includes a minimum load threshold; the minimum load threshold util2 is determined by the following expression: util2=max(smif_M / fmax_M*ca_M*sa2,smif_B / fmax_B*ca_B*sa2); where smif_M is the first minimum frequency limit; smif_B is the second minimum frequency limit; fmax_B is the maximum frequency of the large core; ca_B is the maximum computing power of the large core; and sa2 is a preset constant.

[0025] In one possible implementation of the first aspect, determining whether there is a device power consumption gain when migrating the candidate thread corresponding to the largest thread load to run on the large core includes: calculating the load difference, which is the difference between the thread loads corresponding to the candidate threads; determining that there is a device power consumption gain when the absolute value of the load difference is greater than the load difference threshold; and determining that there is no device power consumption gain when the absolute value of the load difference is less than the load difference threshold; wherein the load difference threshold is determined based on the maximum computing power and the number of frequency points of the medium core.

[0026] In this implementation, since the frequency of the medium core will decrease after the target thread uses a large core, the difference between the load difference threshold determined based on the medium core frequency and the maximum computing power and the load of the corresponding thread of the candidate thread can be directly compared to determine whether there is a device power consumption gain. This can determine whether the target thread should use a large core, thereby improving processing efficiency.

[0027] In one possible implementation of the first aspect, the load difference threshold is determined using the following expression:

[0028] util3 = ca_M / nf_M * sa3; where util3 is the load difference threshold; ca_M is the maximum computing power of the middle core; nf_M is the number of frequency points of the middle core; and sa3 is a preset coefficient.

[0029] In another possible implementation of the first aspect, determining whether there is a device power consumption gain when the candidate thread corresponding to the largest thread load is migrated to run on the large core includes: determining a first device power consumption and determining a second device power consumption; the first device power consumption is the device power consumption before the candidate thread corresponding to the largest thread load is migrated to run on the large core; the second device power consumption is the device power consumption after the candidate thread corresponding to the largest thread load is migrated to run on the large core; wherein, the first device power consumption and the second device power consumption are determined based on a preset energy efficiency table; if the first device power consumption is greater than the second device power consumption, it is determined that there is a device power consumption gain; if the first device power consumption is less than or equal to the second device power consumption, it is determined that there is no device power consumption gain.

[0030] In one possible implementation of the first aspect, the power consumption P1 of the first device is determined by the following expression:

[0031] P1 = P_M(fb_M) * uMsum;

[0032] Where fb_M is the first medium core frequency before the candidate thread corresponding to the largest thread load is migrated to the big core; P_M(fb_M) is the energy efficiency value corresponding to the first medium core frequency; uMsum is the total load on the medium core before migrating to the big core; the energy efficiency value corresponding to the first medium core frequency is determined based on the energy efficiency table.

[0033] In one possible implementation of the first aspect, the power consumption P2 of the second device is determined by the following expression:

[0034] P2=P_M(fa_M)*(uMsum–uBsum)+P_B(freq_B)*uBsum;

[0035] Wherein, fa_M is the second intermediate core frequency after the candidate thread corresponding to the largest thread load is migrated to run on the big core; freq_B is the big core frequency after the candidate thread corresponding to the largest thread load is migrated to run on the big core; P_M(fa_M) is the energy efficiency value corresponding to the second intermediate core frequency; P_B(freq_B) is the energy efficiency value corresponding to the big core frequency; uBsum is the total load on the big core after migration to run on the big core; wherein, the energy efficiency values ​​corresponding to the second intermediate core frequency and the energy efficiency values ​​corresponding to the big core frequency are determined based on the energy efficiency table.

[0036] In one possible implementation of the first aspect, the first intermediate core frequency, the second intermediate core frequency, and the large core frequency are determined by the following expression:

[0037] fb_M or fa_M=X / ca_M*fmax_M*C;

[0038] freq_B = Y / ca_B * fmax_B * C;

[0039] Where X is the total load on the most heavily loaded medium core; Y is the total load on the large core after the candidate thread corresponding to the largest thread load is migrated to run; ca_M is the maximum computing power of the medium core; ca_B is the maximum computing power of the large core; fmax_M is the maximum frequency of the medium core; fmax_B is the maximum frequency of the large core; and C is a preset constant.

[0040] In one possible implementation of the first aspect, migrating the target thread from the medium core to the large core includes: binding the target thread to the large core; or, setting a core selection priority for the target thread and selecting a core for the target thread based on the core selection priority; wherein, the large core has the highest core selection priority, and when the large core is running normally, the target thread is migrated to the large core based on the core selection priority; when the large core is running abnormally, the target thread is migrated to the medium core based on the core selection priority.

[0041] In this implementation, migrating the target thread by binding it to a large core ensures that the target thread will run on the large core until the next core selection. Migrating the target thread by prioritizing core selection is more flexible than continuously binding the target thread to a large core, thus preventing the target thread from being blocked in the event of a large core failure.

[0042] In one possible implementation of the first aspect, the core selection method further includes: if the target thread is not present among the candidate threads, and a candidate thread running on a large core exists, the candidate thread running on the large core is migrated to a medium core. In this implementation, in low-load scenarios (corresponding to the first state) and medium-load scenarios (corresponding to the third state and without device power consumption gain), since not running the candidate thread on the large core will not affect performance, all candidate threads can be migrated to the medium core to save device power consumption.

[0043] In one possible implementation of the first aspect, the target application includes a game application.

[0044] Secondly, this application provides an electronic device, including: one or more processors and a memory, the memory being coupled to the processor; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device performs the following steps: starting a target application; obtaining frequency limiting values ​​for the medium core and the large core, and determining a load threshold based on the frequency limiting values ​​for the medium core and the large core; wherein the frequency limiting values ​​are dynamically set based on the operating status of the target application and the electronic device; when a target thread exists among candidate threads and the target thread is running on the medium core, migrating the target thread from the medium core to the large core; the target thread is determined based on the load threshold and the thread load of the candidate threads; the candidate thread is the application thread of the target application.

[0045] In one possible implementation of the second aspect, the application thread includes a rendering thread and at least one logical thread. The rendering thread is the application thread in the target application used for frame output, and the logical thread is the application thread that has a wake-up relationship with the rendering thread and is related to frame output. The candidate threads include the rendering thread and the logical thread with the heaviest historical load.

[0046] In one possible implementation of the second aspect, the application thread includes a rendering thread and at least one logical thread. The rendering thread is an application thread in the target application used for frame output, and the logical thread is an application thread that has a wake-up relationship with the rendering thread and is related to frame output. When the above computer instructions are executed by the processor, the electronic device further performs the following steps: selecting candidate threads based on the migration priority of the application threads, the candidate threads including the two application threads with the highest migration priority; the migration priority is set based on the historical load of the application threads; wherein, if the target thread is not among the selected candidate threads, a new candidate thread is selected based on the migration priority.

[0047] In one possible implementation of the second aspect, the number of large cores is less than the number of candidate threads, with only one candidate thread running on a large core.

[0048] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: after the target application outputs frames n times, the frequency limiting values ​​of the medium core and the large core are obtained; n is a positive integer greater than or equal to 1; wherein, the thread load corresponding to the candidate thread is the average of the thread loads of n single frames; the n single-frame thread loads are thread loads that correspond one-to-one with the n output frames; the single-frame thread load is determined after the frame output based on the running time of the candidate thread and the frequency of the core.

[0049] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: if the candidate thread is running on a large core, the thread load corresponding to the candidate thread is corrected using a correction factor; wherein the correction factor is the ratio of a first load and a second load, the first load being the thread load when the candidate thread is running on a medium core, and the second load being the thread load when the candidate thread is running on a large core; the candidate thread corresponding to the first load and the candidate thread corresponding to the second load are the same.

[0050] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: before correction, if the candidate thread on the big core changes, the correction coefficient is updated based on the first load and the second load corresponding to the changed candidate thread; if the updated correction coefficient is less than a preset first coefficient threshold, the first coefficient threshold is used as the correction coefficient; if the updated correction coefficient is greater than a second coefficient threshold, the second coefficient threshold is used as the correction coefficient; the second coefficient threshold is greater than the first coefficient threshold.

[0051] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining the load state of the candidate thread based on a load threshold and the thread load of the candidate thread; if the load state is a first state, determining that there is no target thread among the candidate threads; if the load state is a second state, determining that there is a target thread among the candidate threads, and the target thread is the candidate thread corresponding to the largest thread load; the load indicated by the second state is higher than the load indicated by the first state.

[0052] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: if the load state is the third state, determine whether there is a device power gain in migrating the candidate thread corresponding to the largest thread load to run on the big core; the load indicated by the third state is higher than the load indicated by the first state and lower than the load indicated by the second state; if there is a device power gain, take the candidate thread corresponding to the largest thread load as the target thread; if there is no device power gain, determine that there is no target thread among the candidate threads.

[0053] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining the load state as a first state when the maximum value of the load corresponding to the candidate thread is less than the minimum load threshold; determining the load state as a second state when the maximum value of the load corresponding to the candidate thread is greater than the maximum load threshold; and determining the load state as a third state when the maximum value of the load corresponding to the candidate thread is greater than the minimum load threshold and less than the maximum load threshold.

[0054] In one possible implementation of the second aspect, the frequency limit value includes a first maximum frequency limit corresponding to the core, and the load threshold includes a maximum load threshold; when the above computer instructions are executed by the processor, the electronic device further performs the following steps: determining the maximum load threshold util1 using the following expression:

[0055] util1=smaf_M / fmax_M*ca_M*sa1;

[0056] Wherein, smaf_M is the first maximum frequency limit; fmax_M is the maximum frequency of the middle core; ca_M is the maximum computing power of the middle core; and sa1 is a preset constant.

[0057] In one possible implementation of the second aspect, the frequency limiting value further includes a first minimum frequency limit corresponding to the medium core and a second minimum frequency limit corresponding to the large core; the load threshold further includes a minimum load threshold; when the above computer instructions are executed by the processor, the electronic device further performs the following steps: determining the minimum load threshold util2 using the following expression:

[0058] util2=max(smif_M / fmax_M*ca_M*sa2,smif_B / fmax_B*ca_B*sa2);

[0059] Wherein, smif_M is the first minimum frequency limit; smif_B is the second minimum frequency limit; fmax_B is the maximum frequency of the big core; ca_B is the maximum computing power of the big core; and sa2 is a preset constant.

[0060] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: calculating a load difference, which is the difference between the thread loads corresponding to the candidate threads; determining a device power gain if the absolute value of the load difference is greater than a load difference threshold; and determining no device power gain if the absolute value of the load difference is less than the load difference threshold; wherein the load difference threshold is determined based on the maximum computing power of the core and the number of frequency points.

[0061] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining the load difference threshold using the following expression:

[0062] util3 = ca_M / nf_M * sa3;

[0063] Where util3 is the load difference threshold; ca_M is the maximum computing power of the middle core; nf_M is the number of frequency points of the middle core; and sa3 is a preset coefficient.

[0064] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining a first device power consumption and determining a second device power consumption; the first device power consumption is the device power consumption before the candidate thread corresponding to the maximum thread load migrates to the big core for operation; the second device power consumption is the device power consumption after the candidate thread corresponding to the maximum thread load migrates to the big core for operation; wherein the first device power consumption and the second device power consumption are determined based on a preset energy efficiency table; if the first device power consumption is greater than the second device power consumption, it is determined that there is a device power consumption gain; if the first device power consumption is less than or equal to the second device power consumption, it is determined that there is no device power consumption gain.

[0065] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining the power consumption P1 of the first device using the following expression:

[0066] P1 = P_M(fb_M) * uMsum;

[0067] Where fb_M is the first medium core frequency before the candidate thread corresponding to the largest thread load is migrated to the big core; P_M(fb_M) is the energy efficiency value corresponding to the first medium core frequency; uMsum is the total load on the medium core before migrating to the big core; the energy efficiency value corresponding to the first medium core frequency is determined based on the energy efficiency table.

[0068] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining the power consumption P2 of the second device using the following expression:

[0069] P2=P_M(fa_M)*(uMsum–uBsum)+P_B(freq_B)*uBsum;

[0070] Wherein, fa_M is the second intermediate core frequency after the candidate thread corresponding to the largest thread load is migrated to run on the big core; freq_B is the big core frequency after the candidate thread corresponding to the largest thread load is migrated to run on the big core; P_M(fa_M) is the energy efficiency value corresponding to the second intermediate core frequency; P_B(freq_B) is the energy efficiency value corresponding to the big core frequency; uBsum is the total load on the big core after migration to run on the big core; wherein, the energy efficiency values ​​corresponding to the second intermediate core frequency and the energy efficiency values ​​corresponding to the big core frequency are determined based on the energy efficiency table.

[0071] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining the first intermediate core frequency, the second intermediate core frequency, and the large core frequency using the following expressions:

[0072] fb_M or fa_M=X / ca_M*fmax_M*C;

[0073] freq_B = Y / ca_B * fmax_B * C;

[0074] Where X is the total load on the most heavily loaded medium core; Y is the total load on the large core after the candidate thread corresponding to the largest thread load is migrated to run; ca_M is the maximum computing power of the medium core; ca_B is the maximum computing power of the large core; fmax_M is the maximum frequency of the medium core; fmax_B is the maximum frequency of the large core; and C is a preset constant.

[0075] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: binding the target thread to a large core; or, setting a core selection priority for the target thread, and selecting a core for the target thread based on the core selection priority; wherein, the large core has the highest core selection priority, and when the large core is running normally, the target thread is migrated to the large core for operation based on the core selection priority; when the large core is running abnormally, the target thread is migrated to the medium core for operation based on the core selection priority.

[0076] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: if the target thread is not present among the candidate threads, and if a candidate thread running on a large core exists, the candidate thread running on the large core is migrated to a medium core for execution.

[0077] In one possible implementation of the second aspect, the target application includes a game application.

[0078] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor in an electronic device, causes the electronic device to perform the core selection method as described in the first aspect and any possible implementation thereof.

[0079] Fourthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect and any possible implementation thereof. The computer may be the aforementioned electronic device.

[0080] Fifthly, embodiments of this application provide a chip, the chip including a processor, the processor being configured to invoke a computer program in memory to execute the core selection method as described in any one of the first aspects.

[0081] Understandably, the beneficial effects achieved by the electronic device of any possible implementation of the second aspect, the computer-readable storage medium of the third aspect, the computer program product of the fourth aspect, and the chip of the fifth aspect can be referred to as the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0082] Figure 1 This is a simplified diagram illustrating thread execution.

[0083] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0084] Figure 3 A software structure block diagram of an electronic device provided in an embodiment of this application;

[0085] Figure 4 A schematic flowchart of a core selection method provided in an embodiment of this application;

[0086] Figure 5 This application provides a schematic diagram of the comparison of large cores in a medium-load scenario.

[0087] Figure 6 A simplified schematic diagram illustrating another thread operation provided in an embodiment of this application;

[0088] Figure 7 This is a schematic diagram of the interaction timing of a core selection method provided in an embodiment of this application;

[0089] Figure 8 This application provides an illustration of an application scenario for a core selection method.

[0090] Figure 9 This is a structural block diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0091] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., are not necessarily different. Also, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0092] To optimize performance and power consumption, most current mobile phones, tablets, laptops, and other electronic devices use a multi-core heterogeneous architecture for their central processing units (CPUs). A multi-core heterogeneous architecture means that the CPU includes multiple cores, which are categorized into small cores, medium cores, and large cores.

[0093] For example, taking an eight-core CPU as an example, a small core cluster can have 4 small cores, a medium core cluster can have 3 medium cores, and a large core cluster can have 1 large core. That is, for an eight-core CPU, there can be 4 small cores, 3 medium cores, and 1 large core. Therefore, a multi-core heterogeneous architecture can also be called a small-medium-large core architecture.

[0094] In a small-medium-large core architecture, the performance and power consumption of the multiple cores differ. The core performance, from highest to lowest, is categorized as large cores, medium cores, and small cores. Correspondingly, the power consumption of the cores, from highest to lowest, is also categorized as large cores, medium cores, and small cores. In other words, both performance and power consumption follow the order: large cores > medium cores > small cores. That is, the higher the core performance, the higher the power consumption required.

[0095] Therefore, to balance application performance and electronic device power consumption, it's necessary to rationally schedule the use of small, medium, and large cores. For example, to prevent performance issues, heavily loaded threads of an application need to use large cores. Lightly loaded threads, which have lower performance requirements, can omit large cores to save power. However, because the number of large cores is limited—most current CPUs have only 1-2 large cores—determining which large core to use for an application with multiple heavily loaded threads becomes a critical problem to solve.

[0096] Regarding the question of which heavily loaded threads should be assigned to the large core, there are currently different core selection strategies for different applications. For popular applications with a large user base (such as popular games), electronic device developers (such as mobile phone developers) will generally bind a certain portion of the heavily loaded threads in the popular application to the large core, and fine-tune a set of parameters specifically for this popular application. By fine-tuning the parameters, they can ensure that after the heavily loaded threads are bound to the large core, a better performance and power consumption can be achieved.

[0097] For example, Figure 1 A simplified diagram illustrating thread execution is shown.

[0098] Figure 1 The CPU shown is an octa-core CPU. CPU0, CPU1, and CPU2 are small cores; CPU3, CPU4, CPU5, and CPU6 are medium cores; and CPU7 is a large core. (Reference) Figure 1 As shown in (1), because the target thread is fixedly bound to the big core, the target thread will always run on the big core CPU7.

[0099] However, a specific thread of an application (such as a game application), such as Figure 1 The target thread in the process is fixed to the large core, and changes in application scenarios (such as gaming scenarios) can cause thread bottlenecks on the medium core, leading to frame drops. Figure 1 Taking the target thread as an example, specifically, once the target thread is fixedly bound to the large core, it means that the thread running on the large core will always be the target thread; that is, the thread running on the large core will not change with the application scenario. However, as the application scenario (such as a game scenario) changes, the target thread may not always be the most heavily loaded thread. In other words, the most heavily loaded thread in the application may not always be the target thread fixed on the large core. In this case, the actual most heavily loaded thread in the application cannot migrate to the large core and will continue to run on the medium core. Thus, if the computing power of the medium core cannot support the operation of this most heavily loaded thread, it will cause the most heavily loaded thread on the medium core to experience frame drops and other abnormal issues due to computing power bottlenecks.

[0100] For less popular applications (such as less popular games) with a smaller user base, the sheer number of such applications (i.e., a vast number of other less popular games) makes it impractical to fine-tune parameters for each one individually, given the time and memory constraints. Therefore, for a large number of less popular applications, a single set of universal parameters is currently used. This means configuring a universal core selection strategy. Common core selection strategies include energy-aware scheduling (EAS) and fixed load thresholds.

[0101] EAS is a core selection strategy based on overall energy consumption. However, actual observation shows that EAS primarily selects medium-sized cores, rarely using large cores for heavy-load threads, and is prone to repetitive switching (i.e., threads frequently switch between large and small cores). Figure 1 As shown in (2), the target thread frequently switches between various medium-sized cores (CPU3-CPU6) and large-sized cores (CPU7). Therefore, the performance and power consumption of the EAS core selection strategy are relatively poor.

[0102] The fixed load threshold core selection strategy configures a fixed load threshold. When the total thread load of an application exceeds this threshold, the thread with the heaviest load is selected for the high-performance core. However, because thread load calculations vary across different cores, frequent switching can occur. Furthermore, since the optimal load threshold varies significantly across different applications and chip platforms, the universality of this fixed load threshold strategy is poor, failing to guarantee good performance and power efficiency across all application scenarios.

[0103] Thread load refers to the amount of computing power required by a thread, which is usually represented by the util (load) value in the kernel.

[0104] Based on this, embodiments of this application provide a core selection method. The core selection method provided by embodiments of this application is applicable to various application scenarios and chip platforms, has high versatility, and thus ensures good performance and power consumption under various application scenarios.

[0105] In some embodiments, the core selection method provided in this application is applied to electronic devices, primarily in application scenarios requiring core selection. For example, gaming is a major scenario for users of electronic devices, and frame rate, heat generation, and power consumption within game applications significantly impact the user's gaming experience. Therefore, to balance game performance and electronic device power consumption in gaming scenarios, the core selection method provided in this application can be applied to various game applications, including popular games and a vast number of less popular games.

[0106] Specifically, in this embodiment, although different chip platforms have different computing power (i.e., different CPU cores have different computing power), the load calculation is based on the core's frequency (frequency level). Therefore, this embodiment mainly considers using the core's frequency limit value to determine the load threshold used for core selection.

[0107] Then, the electronic device determines the target thread that can be migrated to the big core based on the load threshold determined by the frequency limit value and the thread load of the candidate thread, and migrates the target thread to the big core for execution.

[0108] Among them, candidate threads are application threads in the target application that need to run on large cores. Generally, candidate threads are heavy-load threads in the target application that have been under heavy load for a long time, based on historical load.

[0109] Thus, based on the actual business needs of applications, different applications (such as different game applications) generally have their own frequency limit settings. At the same time, based on other business needs, such as device power consumption requirements, there are corresponding adjustment strategies to adjust the core frequency limit accordingly. For example, the temperature of electronic devices has a significant impact on power consumption. When the temperature of an electronic device exceeds a certain value, the core frequency limit will be dynamically adjusted to a lower value according to the corresponding adjustment strategy, thereby reducing power consumption and preventing the temperature of the electronic device from continuing to rise.

[0110] Therefore, frequency limiting values ​​are typically dynamically set based on the currently running target application and the operating state of the electronic device. In other words, the CPU core frequency limit itself changes dynamically according to application requirements and device power consumption demands. Determining the load threshold for core selection based on the frequency limit ensures that the load threshold also changes dynamically with the target application and the operating state of the electronic device, such as changing with application requirements and power consumption demands. This allows for dynamic load differentiation regardless of application scenario or chip platform. Compared to fixed load thresholds, this approach is more versatile and applicable to various applications (including applications with a large number of users and applications with a small number of users) and chip platforms, ensuring good performance and power efficiency across different application scenarios.

[0111] In some embodiments, the aforementioned electronic device may include at least one of the following: mobile phone, foldable electronic device, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, wearable device, in-vehicle device, smart home device, or smart city device. This application does not impose any special limitation on the specific type of the electronic device.

[0112] For example, Figure 2 A schematic diagram of the structure of an electronic device is shown.

[0113] like Figure 2 As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) connector 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera module 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0114] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0115] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0116] The processor can generate operation control signals based on the instruction opcode and timing signals to control instruction fetching and execution. Specifically, in this embodiment, the processor 110 can dynamically determine the load threshold based on the core's frequency limit value, and then the processor 110 can select the target thread to migrate to the large core for execution based on the determined load threshold and thread load.

[0117] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 may be a cache memory. This memory can store instructions or data that the processor 110 has used or that are used frequently. If the processor 110 needs to use the instruction or data, it can directly retrieve it from this memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0118] In some embodiments, the processor 110 may include one or more interfaces. These interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc. The processor 110 can connect to modules such as touch sensors, audio modules, wireless communication modules, displays, and camera modules through at least one of these interfaces.

[0119] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0120] Internal memory 121 can be used to store computer executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phone book, etc.). In addition, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional methods or data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory disposed in the processor.

[0121] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the electronic device 100.

[0122] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0123] Electronic device 100 can implement display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information. In some embodiments, electronic device 100 may include one or more display screens 194.

[0124] The electronic device 100 can implement camera functions through a camera module 193, ISP, video codec, GPU, display screen 194, and application processor (AP), neural network processor (NPU), etc. In some embodiments, the camera module 193 may include a front-facing camera module and a rear-facing camera module, and the camera module 193 may also consist of two or more cameras.

[0125] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0126] Button 190 may include a power button, volume buttons, etc. Motor 191 may generate vibration feedback. Indicator 192 may be an indicator light used to indicate messages, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card.

[0127] In some embodiments, the software system of the electronic device 100 may adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture of Android... TM Taking the system as an example, the software structure of electronic device 100 is illustrated.

[0128] For example, Figure 3 A software architecture block diagram of an electronic device is shown.

[0129] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android... TM The system is divided into five layers, from top to bottom: application layer, application framework layer, Android runtime (ART) and system library (native), hardware abstraction layer (HAL) and kernel layer.

[0130] The application layer can include a series of application packages. For example... Figure 3 As shown, the application package may include applications such as games, gallery, calendar, maps, music, SMS, calls, navigation, Bluetooth, and video. For ease of explanation, the applications to be selected can be referred to as target applications. In a specific embodiment, target applications include game applications.

[0131] like Figure 3 As shown, the application framework layer may include a window manager, activity manager, input manager, resource manager, notification manager, view system, content provider, etc.

[0132] The window manager provides a window management service (WMS), which can be used for window management, window animation management, surface management, and as a relay station for the input system.

[0133] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, etc.

[0134] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0135] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0136] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0137] The Activity Manager Service (AMS) can be used to start, switch, and schedule system components (such as activities, services, content providers, and broadcast receivers), as well as manage and schedule application processes.

[0138] The input manager can provide an input management service (IMS), which can be used to manage system inputs, such as touchscreen input, keypad input, and sensor input. IMS retrieves events from input device nodes and, through interaction with the WMS, distributes these events to the appropriate windows.

[0139] The Android runtime consists of the core libraries and the Android runtime itself. The Android runtime is responsible for converting source code into machine code. The Android runtime primarily employs ahead-of-time (AOT) compilation and just-in-time (JIT) compilation technologies. The core libraries mainly provide basic Java class library functionalities, such as libraries for basic data structures, mathematics, I / O, tools, databases, and networking. The core libraries provide APIs for users to develop Android applications.

[0140] The system library can include multiple functional modules, such as a media library and a function library. The media library supports various audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The function library provides developers with API interfaces for various services, facilitating rapid integration and implementation of various functionalities.

[0141] In some embodiments, the system library also includes a scheduling service, such as a gamesscheduler. The core selection method provided in this application embodiment can be primarily executed by the scheduling service.

[0142] Specifically, the scheduling service can receive frame output notifications from the target application. Each time a frame output notification is received, the scheduling service can obtain the thread load (i.e., single-frame thread load) corresponding to each candidate thread in the target application during the rendering of that frame from the kernel layer. Simultaneously, the scheduling service can also obtain dynamically changing frequency limits and determine a load threshold based on these limits. Then, the scheduling service uses the load threshold and thread load to determine whether there are any target threads that need to be migrated to run on larger cores.

[0143] The Hardware Abstraction Layer (HAL) runs in user space, encapsulates kernel drivers, and provides calling interfaces to higher layers. The kernel layer acts as the layer between hardware and software. Figure 3 As shown, the Hardware Abstraction Layer (HAL) can include display HAL, audio HAL, camera HAL, Bluetooth HAL, etc. The kernel layer contains at least display drivers, audio drivers, camera drivers, and Bluetooth drivers.

[0144] In some embodiments, the kernel layer also includes a thread load calculation module. This module can calculate the thread load (i.e., single-frame thread load) corresponding to candidate threads after the application frames are generated.

[0145] The core selection method proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be noted that the core selection method in the following embodiments can all be implemented in the electronic device 100 having the above-described hardware structure.

[0146] For ease of description, in this embodiment of the application, the three clusters of a CPU with a small, medium, and large core architecture are represented by silver, gold, and prime, respectively. The small core corresponds to the silver core, the medium core to the gold core, and the large core to the prime core. For CPUs with only two clusters, this embodiment considers them as CPUs without small cores, only having medium and large cores. That is, since threads requiring large cores are usually heavily loaded, these threads are generally not assigned to small cores but will switch between medium and large cores. Therefore, the core selection method provided in this embodiment mainly selects between medium and large cores, without considering the selection of small cores.

[0147] Figure 4 A flowchart illustrating a kernel selection method is shown. For example... Figure 4As shown, the selection method provided in this application includes steps S401-S405, which are described below in conjunction with... Figure 4 The steps shown provide a detailed description of the selection method provided in the embodiments of this application.

[0148] S401, Electronic devices acquire frequency limiting values.

[0149] The frequency limiting values ​​include a minimum frequency limiting value and a maximum frequency limiting value, representing the minimum and maximum adjustable frequency points of the CPU core. In this embodiment, scaling_min_freq represents the minimum frequency limiting value, i.e., the minimum adjustable frequency point. scaling_max_freq represents the maximum frequency limiting value, i.e., the maximum adjustable frequency point.

[0150] Understandably, each CPU core has a series of frequency points (i.e., a set of frequency points), which are typically supported by hardware and can be configured and adjusted. Therefore, small, medium, and large cores each have their own frequency limit values. In this embodiment, the frequency limit values ​​of different clusters are represented using a node + cluster approach. For example, `scaling_min_freq_gold` represents the minimum frequency limit value for the medium core, and `scaling_max_freq_gold` represents the maximum frequency limit value for the medium core. `scaling_min_freq_prime` represents the minimum frequency limit value for the large core, and `scaling_max_freq_prime` represents the maximum frequency limit value for the large core.

[0151] In some embodiments, before the electronic device dynamically sets the core frequency limit value based on the target application and the operating state of the electronic device, that is, before the frequency limit value is dynamically adjusted based on actual application service requirements and device power consumption requirements, the frequency limit value can be a parameter set by the factory. For example, assume the frequency point set of the large core is:

[0152] [1017600,1209600,2841600,……3072000,3283200,3513600,3801600,4089600,4204800,4320000]. Therefore, the lowest frequency limit for this large core is 1017600, and the highest frequency limit is 4320000.

[0153] In other embodiments, the frequency limit value can also be a dynamically adjusted value based on actual application service requirements and device power consumption requirements. For example, different minimum and maximum frequency limit values ​​can be configured for different applications (such as gaming applications), meaning each gaming application will have its own frequency limit setting. As another example, the electronic device can also dynamically adjust the frequency limit value based on temperature. When the temperature of the electronic device exceeds a certain value, a lower frequency limit value can be set to reduce power consumption and prevent the temperature of the electronic device from continuing to rise.

[0154] It should be noted that the dynamic adjustment of the frequency limit value is not limited to the aforementioned application, temperature, and other service requirements, and this application embodiment does not impose any limitations on this. Furthermore, the adjustment strategy for the dynamic adjustment of the frequency limit value also depends on the actual strategy configured in the electronic device, and this application embodiment does not impose any limitations on this.

[0155] However, it should be noted that each core has a set of frequency points that the hardware can support. Therefore, even if the frequency limit is dynamically adjusted according to business needs, the minimum frequency limit will not be lower than the lowest frequency point that the hardware can support, and the maximum frequency limit will not be higher than the highest frequency point that the hardware can support.

[0156] S402, the electronic device determines the load threshold based on the frequency limiting value.

[0157] After the electronic device obtains the frequency limiting values ​​for the small and medium cores, it can determine the load threshold used for core selection based on the frequency limiting values ​​for the medium and large cores. In this embodiment, the load threshold includes a maximum load threshold and a minimum load threshold.

[0158] The maximum load threshold indicates that when the thread load of an application thread (such as a candidate thread) reaches this value, the medium core may no longer be able to accommodate the thread, and a large core is needed; otherwise, performance issues may occur.

[0159] The expression for calculating the maximum load threshold util_max (i.e., util1) is as follows:

[0160] util_max=scaling_max_freq_gold / fmax_gold*capacity_gold*scale_max.

[0161] Among them, scaling_max_freq_gold (i.e., smaf_M) is the highest frequency limit of the middle core. fmax_gold (i.e., fmax_M) is the maximum frequency of the middle core, that is, the maximum value in the set of frequency points corresponding to the middle core. capacity_gold (i.e., ca_M) is the maximum computing power of the middle core, that is, the computing power at which it runs at the highest frequency that the hardware can support.

[0162] In other words, fmax_gold and capacity_gold are hardware constants of electronic devices, and they do not change with application (such as game applications) or business requirements such as temperature.

[0163] scale_max (i.e. sa1) is a constant that represents the amount of load margin left. Since it is necessary to determine whether to migrate to a larger core and to determine the threads to be moved to the larger core based on the relationship between the thread load and the maximum load threshold util_max, the constant scale_max can avoid triggering core migration after the thread load is fully loaded.

[0164] That is, the actual maximum load threshold is scaling_max_freq_gold / fmax_gold*capacity_gold. Multiplying this by a preset constant scale_max can appropriately reduce the maximum load threshold, thereby triggering core migration before the thread load reaches the actual maximum load threshold.

[0165] In some embodiments, the scale_max during EAS frequency modulation is typically 0.8, while this embodiment uses 0.7, which provides more margin compared to EAS. However, scale_max can be adjusted as needed, and this embodiment does not impose any limitations on it.

[0166] The minimum load threshold indicates that when the thread load of an application thread (such as a candidate thread) is lower than this value, it means that the minimum frequency of the medium core can meet the performance requirements of the application (such as a game application), or that the current operating load is not yet at the minimum frequency of the large core, and using the large core on the thread is a waste of power. The calculation expression for the minimum load threshold util_min (i.e., util2) is as follows:

[0167] util_min=max(scaling_min_freq_gold / fmax_gold*capacity_gold*scale_min, scaling_min_freq_prime / fmax_prime*capacity_prime*scale_min).

[0168] Here, scaling_min_freq_gold is the minimum frequency limit for the medium-sized core, and scaling_min_freq_prime is the minimum frequency limit for the large-sized core. fmax_prime (i.e., fmax_B) is the maximum frequency of the large-sized core, which is the maximum value in the set of frequency points corresponding to the large-sized core. capacity_prime (i.e., ca_B) is the maximum computing power of the large-sized core.

[0169] Similarly, `fmax_prime` and `capacity_prime` are hardware constants of the electronic device, which do not change with application requirements (such as gaming applications) or temperature-related business needs. Furthermore, `scale_min` (i.e., `sa2`) is a constant representing the load margin, typically set to 0.8. Of course, `scale_min` can be adjusted as needed, and this embodiment does not impose any limitations on this. That is, if more load margin is required, `scale_min` can be increased accordingly.

[0170] S403, the electronic device determines the load status of candidate threads based on the load threshold and thread load.

[0171] Specifically, after determining the maximum and minimum load thresholds based on the frequency limiting values, the electronic device compares the thread load of the candidate threads corresponding to the target application with the maximum and minimum load thresholds to determine the current load status of the candidate threads in the target application. The electronic device then determines whether any target threads need to be migrated to run on larger cores based on the load status of the candidate threads.

[0172] Taking game applications as an example, the heavy-load threads that need to run on large cores in game applications are typically rendering threads and logic threads. Therefore, candidate threads in a game application can include rendering threads and logic threads. As can be understood, the rendering thread is the thread used for frame output in a game application, that is, the thread that performs queuebuffer operations. The logic thread is the thread that has a wake-up relationship with the rendering thread, is related to frame output, and has the heaviest load.

[0173] In this embodiment, render represents the rendering thread, main represents the logic thread, util_render represents the thread load of the render thread, and util_main represents the thread load of the logic thread main.

[0174] The process for determining the load status is as follows:

[0175] If max(util_render, util_main) < util_min, meaning the load values ​​util_render and util_main of both the rendering thread and the logic thread are less than the minimum load threshold util_min, then the two heaviest-loaded threads in the game application are in a low-load state. Therefore, the electronic device can determine that the current load state of the candidate threads in the game application is a low-load scenario (i.e., the first state). In a low-load scenario, it means that the candidate threads in the game application do not currently require large cores. Therefore, it can be determined that large cores are not needed in a low-load scenario, and the core selection strategy is to have both the rendering thread and the logic thread on medium cores. In this way, large cores can automatically hibernate in low-load scenarios to save power.

[0176] If `max(util_render, util_main) > util_max`, meaning the maximum load value between `util_render` and `util_main` for the rendering thread and the logic thread is greater than the maximum load threshold `util_max`, it indicates that there is a candidate thread in the game application under high load. Therefore, the electronic device can determine that the current load state of the candidate thread in the game application is a high-load scenario. For a high-load scenario (i.e., the second state), it means that the medium-core cannot meet the running requirements of the candidate thread. To ensure the normal operation of the candidate thread and guarantee the performance of the game application, the electronic device determines that the candidate thread of the game application needs to be migrated to the large core, so that the large core can provide powerful computing power to improve game performance. Therefore, the electronic device migrates the candidate thread with the higher load between the rendering thread (`render`) and the logic thread (`main`) to the large core for execution, while the candidate thread with the lower load continues to run on the medium core, and other threads of the game application do not use the large core.

[0177] If util_min < max(util_render, util_main) < util_max, meaning the maximum value of util_render and util_main is greater than the minimum load threshold util_min and less than the maximum load threshold util_max, placing it between low and high load, then the electronic device can determine that the candidate thread's load state in the game application is a medium load scenario (i.e., the third state). Theoretically, there shouldn't be performance issues in a medium load scenario. To achieve a smooth transition between performance and power consumption, and to improve performance and power efficiency, whether to migrate threads to larger cores mainly depends on power consumption considerations.

[0178] In summary, if an electronic device determines that the load state is a low-load scenario, it can determine that candidate threads do not need to run on large cores. In other words, there are no target threads among the candidate threads that need to be migrated to run on large cores, and the electronic device can choose not to perform a core migration operation. In some embodiments, if it is determined to be a low-load scenario (i.e., the first state), but there are candidate threads that are already running on large cores, the electronic device can migrate the candidate threads from large cores to medium cores in order to save power.

[0179] For example, if both util_render and util_main are less than the minimum load threshold util_min, but the rendering thread is currently running on the big core and the logic thread is running on the medium core, then the rendering thread can be migrated from the big core to the medium core, so that both the rendering thread and the logic thread run on the medium core. This can ensure performance while saving more power in low-load scenarios, thus improving both performance and power consumption.

[0180] If the electronic device determines that the load state is a high load scenario, and the candidate threads are not running on the big core, the performance will be problematic. Therefore, the electronic device executes S404.

[0181] S404, the candidate thread corresponding to the highest thread load is determined as the target thread, and the target thread is migrated to run on a large core. That is, when it is determined that the candidate thread needs to run on a large core, the target thread selected for running on a large core in this embodiment is the candidate thread with the highest thread load. If the selected target thread is running on a medium core, the target thread is migrated to run on a large core.

[0182] Therefore, since the frequency limit value can dynamically change according to application service requirements and power consumption requirements, determining the load threshold used for core selection based on the frequency limit value ensures that the load threshold also dynamically changes based on application service requirements and power consumption requirements. This allows for dynamic load differentiation regardless of application scenario or chip platform. Compared to a fixed load threshold, the load threshold in this embodiment has greater versatility, ensuring good performance and power consumption across various application scenarios. Furthermore, even if the frequency limit value is dynamically adjusted too low, causing candidate threads to easily utilize large cores, the low frequency limit value will reduce core computing power and easily affect performance. Therefore, in this case, the high computing power of large cores can be leveraged to improve performance to some extent by facilitating their use.

[0183] If the electronic device is determined to be under medium load, there is no performance problem. Therefore, whether or not to migrate the thread to the big core is mainly a matter of power consumption. Thus, the electronic device continues to execute S405.

[0184] S405, the electronic device determines whether migrating the candidate thread corresponding to the largest thread load to run on the big core will result in a device power gain (device power benefit).

[0185] If there is a device power gain, the candidate thread corresponding to the largest thread load is the target thread that needs to be migrated to run on the large core. If there is no device power gain, the electronic device can determine that there is no target thread that needs to be migrated to run on the large core among the candidate threads.

[0186] For example, Figure 5 This diagram illustrates a comparison of large cores under medium load conditions. It is understandable that... Figure 5 The diagram shown is a simplified representation of thread execution. "Other threads" refers to other smaller threads within the game application, i.e., application threads other than the main logic thread and the render thread.

[0187] The following embodiments of this application will use the example of the logical thread main having a higher thread load than the rendering thread render to illustrate the process of determining device power consumption gain. That is, it is assumed that the logical thread main is the candidate thread corresponding to the highest thread load, which means that if a large core is needed, the logical thread main is migrated to the large core for execution.

[0188] First of all, with Figure 5 Taking the thread shown as an example, we will use CPU util to map frequency points for a simple derivation.

[0189] That is, assuming the target thread does not use a large core:

[0190] freq_before=(util_main+util_other) / capacity_gold*fmax_gold*1.25.

[0191] When the target thread uses a large core:

[0192] freq_after=(util_render+util_other) / capacity_gold*fmax_gold*1.25.

[0193] freq_prime=util_main / capacity_prime*fmax_prime*1.25.

[0194] Where freq_before (i.e. fb_M) is the target thread (e.g., Figure 5 The logical thread in the middle (i.e., the first middle core frequency) is the frequency of the middle core when the big core is not used. freq_after (i.e., fa_M) is the frequency of the target thread (e.g., ...). Figure 5 The frequency of the middle core (i.e., the second middle core frequency) in the case of a large core (in the logical thread of the middle core). freq_prime (i.e., freq_B) is the target thread (e.g., ... Figure 5 The frequency of large cores in the case of large cores in logical threads.

[0195] It should be noted that, because frequency calculations typically only consider the thread load on the most heavily loaded core, the thread load in the `freq_before` expression is the sum of the two threads on core 1, i.e., `util_main + util_other` (i.e., X). Similarly, the thread load in the `freq_after` expression is the sum of the two threads on core 2, i.e., `util_render + util_other` (i.e., X).

[0196] Similarly, in the freq_prime expression, because Figure 5As shown, only the logical thread `main` runs on the large core, so the total load on the large core is `util_main` (i.e., Y). However, it is understandable that, depending on the actual operation, there may be other threads `other` on the large core, so after the logical thread `main` is migrated to the large core, Y can be `util_main + util_other`.

[0197] Here, 1.25 is a constant C, the opposite of scale_min or scale_max in the above expression. That is, if scale_min or scale_max is 0.8, representing a 20% load margin, then when calculating the core frequency, it needs to be multiplied by the corresponding constant C, i.e., C = 1 / 0.8 = 1.25. It can be understood that 1.25 in the above expression of this application embodiment is the constant C corresponding to when scale_min or scale_max is 0.8, and this constant C will change accordingly as scale_min or scale_max changes. For example, if scale_min or scale_max is 0.7, then the constant C = 1 / 0.7.

[0198] Therefore, the expression for the frequency reduction value freq_diff of whether the target thread uses the large core or the medium core frequency is:

[0199] freq_diff=freq_before-freq_after=(util_main-util_render) / capacity_gold*fmax_gold*1.25.

[0200] Therefore, we can see that among the above expressions, only the load value (util) changes; the others are constants for the same CPU, which are hardware constants that can be directly read. Thus, after the main logical thread uses the large core, the frequency change (freq_diff) of the medium core is only related to the difference between the logical thread and the rendering thread (util_main - util_render).

[0201] In other words, under medium load scenarios, if the target thread uses a large core, the medium core frequency decreases, and the medium core power consumption decreases. However, the large core's power consumption increases when it goes from sleep to running. Therefore, whether the target thread should use a large core depends on whether there is a power consumption gain. Furthermore, if there is a power consumption gain (i.e., the power consumption of the target thread using a large core is lower than the power consumption of the target thread not using a large core), then the target thread should use a large core. Conversely, if there is no power consumption gain (i.e., the power consumption of the target thread using a large core is lower than the power consumption of the target thread not using a large core), then the target thread can choose not to use a large core.

[0202] This is understandable, because the above expression is based on the assumption that the load on the logical thread `main` is higher than that on the rendering thread `render`, so the difference in the expression is (util_main - util_render). Conversely, if the load on the rendering thread `render` is higher than that on the logical thread `main`, then `freq_diff = freq_before - freq_after = (util_render - util_main) / capacity_gold * fmax_gold * 1.25`.

[0203] Therefore, freq_diff can also be expressed as: abs(util_main-util_render) / capacity_gold*fmax_gold*1.25. Here, abs() represents the absolute value.

[0204] In some embodiments, energy efficiency meter calculations can be used to determine whether there is a device power consumption gain.

[0205] Specifically, an energy efficiency table / curve (a curve formed based on the values ​​in the energy efficiency table) is pre-installed in the electronic device. As shown in Table 1 below, the energy efficiency table stores the single-core performance score, power consumption value, and corresponding energy efficiency value = power / single-core score for each core when performing tasks at full load at different frequency points. That is, the energy efficiency table represents the power consumption of a certain calculation at full load at that frequency point, which can be understood as the power consumed per unit load uilt, denoted as P(freq) in this embodiment.

[0206] Table 1

[0207]

[0208] It is understood that the parameters in Table 1 are merely one example in the embodiments of this application and do not constitute any limitation on the core frequency (frep), single-core performance score, or power consumption value.

[0209] Furthermore, electronic devices can determine the device power consumption before implementing a large core (power_before, i.e., P1) and the device power consumption after implementing a large core (power_after, i.e., P2) through the energy efficiency table. The expression for device power consumption is:

[0210] Power consumption of the device before the large core is added: power_before=P_gold(freq_before)*util_gold_sum.

[0211] Power consumption of the device after adding large cores: power_after=P_gold(freq_after)*(util_gold_sum–util_main)+P_prime(freq_prime)*util_main.

[0212] Where `util_gold_sum` represents the total load of the mid-core before the migration, i.e., the sum of the `uitl` values ​​of all threads on the mid-core. In this expression, `util_main` represents the total load of the large core after the migration. It can be understood that the above device power consumption expression is based on... Figure 5 The thread shown is an example. Figure 5 As shown, only the logical thread `main` runs on the large core, so the total load on the large core after migration is `util_main`. However, based on actual conditions, if other threads are running on the large core, then `util_main` in the above expression needs to be replaced with `util_main_sum`, for example, `util_main_sum = util_main + util_other`.

[0213] Then, the electronic device only needs to calculate the difference between `power_before` and `power_after` to determine if there is a power consumption gain. That is, if the device consumes less power on the large core of the target thread, then the target thread is migrated to run on the large core. Otherwise, the target thread is not migrated to the large core. Figure 5 Taking the thread shown as an example, that is, when there is a power consumption gain due to using a large core, the main logical thread is used on a large core, and the thread's running state after using a large core is as follows. Figure 5 The thread execution state corresponding to "after using a large core". Conversely, in the case of no device power gain when using a large core, the logical thread main is not used on the large core, and the thread execution state without using a large core is as follows. Figure 5 The thread running state before the "big core" is mentioned.

[0214] Understandable. Figure 5 The comparison chart shown illustrates the scenario where the thread with the heaviest thread load is not using the large core. If the thread is already using the large core, the same principle applies to deciding whether to allow the candidate thread to use the large core. That is, the device power consumption when using the large core and when not using the large core can be calculated to determine whether to allow the candidate thread to use the large core. This will not be elaborated further.

[0215] In other embodiments, since the energy efficiency table is typically generated under single-core conditions and full load while running a fixed task, the energy efficiency value may vary depending on the task and whether it is under non-single-core conditions. In other words, the configured energy efficiency table may have some errors depending on the task and whether it is under single-core conditions.

[0216] Therefore, to ensure the accuracy of power consumption calculations, this application embodiment also provides a simplified method to determine whether there is a device power consumption gain. That is, as mentioned above, since the frequency of the medium core will decrease after the target thread is moved to the large core, this application embodiment can determine whether there is a device power consumption gain by the magnitude of the medium core frequency reduction. Specifically, if the medium core frequency reduction value freq_diff exceeds one frequency point after the target thread is migrated to run on the large core, it can be determined that there is a device power consumption gain, and therefore the electronic device can decide to migrate the target thread to run on the large core.

[0217] The specific logic of the above simplification method is as follows: Since most threads of an application (such as a game application) run on the medium core, the total load on the medium core is generally higher than that on the large core. Therefore, if a thread is migrated to run on the large core, the frequency of the medium core is significantly reduced, and the power consumption saved is likely to be greater than the power consumption increase from using the large core. The advantage of this is that by simply comparing the difference in thread load between candidate threads, it is possible to directly determine whether the target thread should run on the large core.

[0218] Taking the logic thread and rendering thread of a game application as an example again, it is only necessary to calculate the absolute value of the load difference between util_main and util_render. Then, the device compares the absolute value of the load difference with the load difference threshold util_gap.

[0219] If the absolute value of the load difference is greater than the load difference threshold util_gap (i.e., util3), meaning abs(util_main - util_render) > util_gap, the electronic device determines that the thread can run on the large core, and then migrates the thread with the heaviest load (i.e., the target thread) to run on the large core. For example, assuming the load on the logical thread `main` is heavier than the load on the rendering thread `render`, then the logical thread `main` is migrated to the large core as the target thread, while the rendering thread `render` continues to run on the medium core. Conversely, if the load on the rendering thread `render` is heavier than the load on the logical thread `main`, then the rendering thread `render` is the target thread migrated to the large core, while the logical thread `main` continues to run on the medium core.

[0220] If the absolute value of the load difference is less than the load difference threshold util_gap, i.e., abs(util_main-util_render) < util_gap, the electronic device determines that the target thread will not run on the large core. In other words, whether it is the logic thread main or the rendering thread render, they will continue to run on the medium core.

[0221] In this embodiment, since a large core can be determined to be used as long as the medium core's frequency is reduced by more than one frequency point, the expression for the above-mentioned load difference threshold util_gap is:

[0222] util_gap=capacity_gold / num_freq_gold*scale_gap.

[0223] Here, `num_freq_gold` (i.e., `nf_M`) represents the number of core frequencies, specifically the number of frequencies in the set corresponding to the core. `scale_gap` (i.e., `sa3`) is a preset coefficient, typically set to 1. However, to prevent situations where large cores on certain CPU chips have extremely poor energy efficiency and are unsuitable for threading, the coefficient `scale_gap` can be increased adaptively based on actual needs. Understandably, a larger `scale_gap` indicates a higher difficulty in utilizing large cores.

[0224] In some embodiments, whether the determination of device power consumption gain is made through an energy efficiency table or by calculating the load difference of candidate threads, to ensure the accuracy of the power consumption gain determination, it can be the device power consumption within one cycle, such as when n = 10 frames are output. Alternatively, it can be the power consumption within a preset duration. This application embodiment does not impose any limitations on this. For example, taking the expression abs(util_main-util_render) as an example, if the device power consumption gain is measured in one cycle, then util_main and util_render in the expression are the average values ​​of the thread loads of 10 single frames. If the device power consumption gain is measured in a preset duration, then util_main and util_render in the expression are the average values ​​of the thread loads of each single frame within the preset duration.

[0225] In some embodiments, there are many existing methods for calculating thread load, such as the calculation of util_main and util_render mentioned above. This application embodiment can employ any existing util calculation method, and this application embodiment does not impose any limitations on it. In a specific embodiment, the electronic device can calculate thread load using the number of instructions.

[0226] Specifically, when using the `util` value to represent thread load, the kernel typically records the computing power of the CPU with the highest computing power running continuously at the highest frequency as 1024. Since the CPU with the highest computing power is usually a large core, this 1024 is the maximum computing power (`capacity_prime`) of the large core. At the same time, this maximum computing power of 1024 also acts as a benchmark for the computing power of the large core. For example, if the large core runs at the highest frequency for half the time, its computing power can be recorded as 512. Or, if the large core runs at half the frequency for the entire time, its computing power can also be recorded as 512.

[0227] Correspondingly, using the same method as the large core and with 1024 as the benchmark, the maximum computing power (capacity_gold) of the medium core can also be obtained. That is, the medium core also has a corresponding computing power rating when the CPU is manufactured. For example, if the maximum computing power of the large core is 1024, the maximum computing power of the medium core could be 800. It is understood that the aforementioned maximum computing power of 800 is merely an example of an embodiment of this application and does not constitute any limitation on the maximum computing power of the medium core; it depends on the actual value of the medium core after the CPU is manufactured.

[0228] In this way, electronic devices can calculate the utility of a thread based on the computing power of different cores and the thread's running time and frequency.

[0229] For example, taking the rendering thread running on the mid-core as an example, the expression for calculating the thread load util_render is as follows:

[0230] util_render=runtime / window*cur_freq / fmax_gold*capacity_gold.

[0231] Here, `runtime` represents the runtime of one frame, and `window` is the length of the statistical window, corresponding to the frame rate. For example, based on the actual frame rate, `window` can be 8.333ms, 16.67ms, etc. Therefore, taking 16.67ms as an example, assuming the rendering thread actually spends 12ms running one frame, then `runtime / window = 12 / 16.67`. `cur_freq` is the current frequency of the mid-core. The load calculation principle for threads running on high-cores is the same and will not be elaborated further.

[0232] However, it's important to note that due to the difference in maximum computing power between medium and large cores, the thread utility (util) calculated for the same thread and the same amount of computation will differ between medium and large cores during runtime. Generally, the util calculated on medium cores will be higher than that calculated on large cores. This difference stems from the fact that util is based on runtime, which is related to many other factors, such as Double Data Rate SDRAM (DDR) and cache memory.

[0233] Furthermore, the load differences between threads of different computational types also vary. For example, the load difference between logic threads on medium and large cores is different from that between rendering threads on medium and large cores. In other words, not only is there a certain load difference between medium and large cores, but this load difference is also not fixed, so it is impossible to avoid the impact of this difference through a fixed correction method.

[0234] Therefore, in order to reduce load differences and avoid affecting the accuracy of core selection, this embodiment of the application also needs to dynamically adjust the load difference between medium and large cores. In this embodiment, the dynamic adjustment of load differences involves calculating a correction coefficient utilScale based on the actual util values ​​of the thread on the medium and large cores.

[0235] In a specific embodiment, taking the logical thread `main` as an example, if the calculated thread load `util_main` is 300 when running on a medium-sized core, and 200 when running on a large-sized core, then the correction factor `utilScale` = 300 (i.e., the first load) / 200 (i.e., the second load) = 1.5. Therefore, when calculating the thread load `util_main`, if the logical thread `main` is running on a large-sized core, the calculated thread load `util_main` needs to be multiplied by the correction factor `utilScale` = 1.5 before being compared with the load threshold. In other words, the load difference between the medium-sized and large-sized cores is removed by the correction factor before being compared with the load threshold to determine whether to migrate to a different core.

[0236] It should be noted that the above 300, 200 and the corresponding 1.5 are only examples of embodiments of this application and do not constitute any limitation on the thread load util_main of the logical thread running on the medium core and the large core.

[0237] In some embodiments, as described above, the calculated thread load is used to compare with load thresholds (including the highest load threshold and the lowest load threshold). However, current thread load is typically obtained on a frame-by-frame basis. That is, the application can obtain the thread load corresponding to each frame of image rendered from the kernel. Thus, for applications with highly variable application scenarios, such as games, comparing the thread load of only a single frame with the load threshold may result in significant fluctuations, leading to frequent core migrations, such as... Figure 1 As shown in (2).

[0238] Therefore, to avoid frequent core migration, the thread load in this embodiment can be the average util value of n frames. That is, this embodiment can trigger a core selection after the target application renders n frames. Here, n is a positive integer greater than or equal to 1. For example, an electronic device can use the average util value of 10 frames, 5 frames, or 2 frames as the thread load. This embodiment does not impose any limitation on the specific value of n; n can be set according to actual needs. This avoids frequent core migration, such as... Figure 6 As shown.

[0239] Figure 7 An interactive timing diagram of a core selection method is shown. The following, combined with... Figure 7 The method of Xuanhe provided in the embodiments of this application will be described. For example... Figure 7 As shown, the kernel selection method includes steps S1-S10.

[0240] S1, the target application starts.

[0241] First, in response to the user's startup operation, the target application is launched. The target application is the application that needs to be selected for kernel processing. For example, the target application may include game applications, video applications, etc., which can be specifically set according to the actual kernel selection requirements. This application embodiment does not impose any limitations on this. After the target application is launched, it can begin to draw and render image frames.

[0242] In this embodiment, the target application notifies the scheduling service of the frame output each time it outputs a frame, i.e., each time it performs a queuebuffer operation. In some embodiments, the target application may notify the scheduling service of the frame output via an intermediate module; this embodiment does not limit this approach.

[0243] S2, the thread load calculation module calculates the single-frame thread load of candidate threads.

[0244] After each frame is rendered, the thread load calculation module in the kernel layer calculates the thread load. That is, after each frame is rendered, each candidate thread corresponds to a thread load calculated by the thread load calculation module. For example, if the candidate threads include the rendering thread (render) and the logic thread (main), then the thread load calculated by the thread load calculation module after each frame includes the rendering thread's thread load (util_render) and the logic thread's thread load (util_main). The thread load of the candidate threads calculated for each frame is referred to in this embodiment as the single-frame thread load of the candidate threads.

[0245] In some embodiments, the single-frame thread load is calculated based on the running time of the candidate thread and the frequency of the cores on which the candidate thread runs. For details, please refer to the description of thread load calculation in the above embodiments; further elaboration will not be repeated here.

[0246] S3, the scheduling service obtains the single-frame thread load.

[0247] Because the kernel layer of an electronic device calculates the single-frame thread load for each candidate thread after the target application outputs a frame, the scheduling service, upon receiving the frame output notification from the target application, can obtain the single-frame thread load for each candidate thread in this frame output from the kernel layer's thread load calculation module.

[0248] S4, the scheduling service calculates the thread load of candidate threads.

[0249] Because the application scenario of the target application may change, to avoid frequent core migration caused by deciding whether to use a large core based on single-frame thread load, the scheduling service needs to trigger core selection only after the target application's cumulative frame output reaches n times, that is, after the target application has completed drawing and rendering n frames. Understandably, the scheduling service can determine the target application's frame output count by counting the number of frame output notifications received.

[0250] In this embodiment, the first processing step of the scheduling service in selecting cores is to calculate the average thread load of the n single frames corresponding to the n output frames. The scheduling service uses this average value as the thread load for comparing candidate threads with a load threshold.

[0251] For example, taking the rendering thread `render` and the logic thread `main` as examples, if n=10, then after every 10 frames are generated, the scheduling service will calculate the average of the thread load of the rendering thread based on the 10 single-frame thread loads obtained from the kernel layer. Similarly, the scheduling service needs to calculate the average of the thread load of the logic thread based on the 10 single-frame thread loads obtained from the kernel layer.

[0252] In some embodiments, due to the load difference between medium and large cores, the calculated thread load needs to be multiplied by a correction factor utilScale to remove the impact of this load difference. To ensure the accuracy of the correction factor utilScale, it needs to be updated in real time based on the running status changes of the candidate threads. Therefore, the scheduling service executes S5-S6 or S7.

[0253] S5: When the candidate thread on the big core changes, the scheduling service updates the correction coefficient.

[0254] In this embodiment, there are two scenarios where candidate threads on the large core change. The first scenario is that a candidate thread running on the large core either appears from zero or disappears. For example, if a cycle consists of n frames, and the large core is empty in the current cycle, but candidate threads (such as rendering threads or logic threads) were running on it in the previous cycle, then the large core's thread count has changed from zero to zero. Similarly, if candidate threads (such as rendering threads or logic threads) are running on the large core in the current cycle, but were empty in the previous cycle, then the large core's thread count has changed from zero to zero in both cycles.

[0255] For the first scenario, the scheduling service obtains the thread load corresponding to the candidate thread that went from non-existent to present or from present to non-existent in these two cycles. Understandably, since this candidate thread went from non-existent to present or from present to non-existent on the large core, one of the two thread loads corresponding to this candidate thread in these two cycles must be the thread load running on the medium core, and the other must be the thread load running on the large core. Therefore, dividing the thread load on the medium core by the thread load on the large core yields the updated correction coefficient utilScale.

[0256] The second scenario is that the candidate thread running on the large core changes. For example, the candidate thread running on the large core in the current cycle is a rendering thread, but the candidate thread running on the large core in the previous cycle was a logic thread; that is, the candidate thread running on the large core has changed from a logic thread to a rendering thread. Similarly, if the candidate thread running on the large core in the current cycle is a logic thread, but the candidate thread running on the large core in the previous cycle was a rendering thread, then the candidate thread running on the large core has changed from a rendering thread to a logic thread. Understandably, to avoid two or more heavily loaded threads running simultaneously on the large core, causing CPU time slice contention and application lag, generally only one heavily loaded thread runs on a large core. That is, in this embodiment, only one candidate thread runs on a large core. For example, for game applications, only a rendering thread or one logic thread runs on the large core.

[0257] For the second scenario, since the candidate thread changes, whether it's the rendering thread or the logic thread, each of these two cycles operates on one mid-core and the other on the large core. Therefore, by obtaining the thread load of the rendering thread or logic thread in these two cycles, and then dividing the thread load on the mid-core by the thread load on the large core, we can obtain the updated correction coefficient utilScale.

[0258] It should be noted that, because the application object of the correction coefficient utilScale in this embodiment is the candidate thread running on the large core, that is, the correction coefficient utilScale = thread load on the medium core (i.e., first load) / thread load on the large core (i.e., second load), the correction coefficient utilScale can be updated accordingly as long as it is determined that the thread operation on the large core has changed. Of course, it is understandable that, based on actual needs, the application object of the correction coefficient utilScale can also be set to the medium core, the principle is the same, and it will not be elaborated further.

[0259] In some embodiments, to prevent abnormal situations from causing the correction coefficient utilScale to be too large or too small, thus affecting core selection. For example, an excessively large correction coefficient can lead to excessive thread load on candidate threads running on large cores. This could result in a situation where the thread load of this candidate thread is always at its maximum, causing it to run indefinitely on the large core. In other words, there is a problem where a candidate thread, after being migrated to a large core, will not be migrated back to a medium core.

[0260] Based on this, the embodiments of this application set a range for the correction coefficient. In the embodiments of this application, the correction coefficient needs to be greater than a first coefficient threshold and less than a second coefficient threshold. For example, taking 0.8-1.8 as an example, that is, if the determined correction coefficient is less than the first coefficient threshold of 0.8, then the correction coefficient needs to be changed to the first coefficient threshold of 0.8 to avoid the correction coefficient being too small. And if the determined correction coefficient is greater than the second coefficient threshold of 1.8, then the correction coefficient needs to be changed to the second coefficient threshold of 0.8 to avoid the correction coefficient being too large.

[0261] S6, the scheduling service uses the updated correction coefficients to correct the thread load of candidate threads on the big cores.

[0262] After the correction factor utilScale is updated, the scheduling service can multiply the corresponding thread load of the candidate threads currently running on the large core by the correction factor utilScale to obtain the final thread load. After removing the load difference between the medium and large cores, the load is compared with the load threshold to determine whether to migrate to the large core.

[0263] S7, when the candidate threads on the big core remain unchanged, the scheduling service uses the original correction coefficient to correct the thread load of the candidate threads on the big core.

[0264] In other words, if the candidate threads on the large core remain unchanged, the scheduling service can determine that there is no need to update the correction coefficient utilScale. Therefore, the scheduling service does not update the correction coefficient utilScale, but directly uses the existing correction coefficient utilScale to correct the thread load of the candidate threads running on the large core. Of course, in this case, there may not be any candidate threads currently on the large core, so the scheduling service may also choose not to perform the correction.

[0265] S8, the scheduling service determines the load threshold based on the frequency limit value.

[0266] In this embodiment, the load threshold includes a maximum load threshold util_max and a minimum load threshold util_min. For the specific implementation of S8, please refer to the description of S402 above; further details will not be provided here.

[0267] S9, the scheduling service determines whether the target thread exists among the candidate threads based on the load threshold and thread load.

[0268] If the target thread exists, the scheduling service executes S10.

[0269] S10, the scheduling service migrates the target thread to run on the big core.

[0270] For the specific implementation of S9 and S10, please refer to the descriptions of S403-S405 above. The principle is the same, so it will not be repeated here.

[0271] In summary, taking the rendering thread and logic thread as examples, if max(util_render, util_main) > util_max, or abs(util_render - util_main) > util_gap && max(util_render, util_main) > util_min, then the thread with the heavier thread load between the rendering thread and the logic thread will be migrated to the large core to run. In other words, the candidate thread corresponding to the largest thread load will run on the large core. Otherwise, both the rendering thread and the logic thread will run on the medium core.

[0272] For example, taking the target applications as game application A and game application B, and the candidate threads as rendering threads and a logic thread, Figure 8 An application scenario diagram of a kernel selection method is shown. The following, combined with... Figure 8 The application scenarios shown illustrate the core selection method of this application embodiment.

[0273] refer to Figure 8In (1) and (3), at the first moment, either game application A or game application B starts running. Simultaneously, at the first moment, the frequency limit value for game application A is frequency limit value 1, and the load threshold determined based on frequency limit value 1 is also load threshold 1. The frequency limit value for game application B is frequency limit value 3, and the load threshold determined based on frequency limit value 3 is also load threshold 3. Furthermore, at the first moment, the thread load for both game application A and game application B is thread load 1.

[0274] Understandably, both frequency limit value 1 and frequency limit value 3 include at least the highest and lowest frequency limit values ​​corresponding to the medium cores and the lowest frequency limit value corresponding to the large cores. Load threshold 1 and load threshold 3 also include the highest and lowest load thresholds. Furthermore, thread load 1 includes the thread load of the rendering thread and the thread load of the logic thread.

[0275] Based on this, when the rendering thread's load is heavier than the logic thread's load, in game application A, thread load 1 and load threshold 1 can determine that the candidate thread running on the high-performance core is the rendering thread (i.e., the target thread), and the candidate thread running on the mid-performance core is the logic thread. Similarly, in game application B, thread load 3 and load threshold 3 can also determine that the candidate thread running on the high-performance core is the rendering thread (i.e., the target thread), and the candidate thread running on the mid-performance core is the logic thread. For specific implementation details, please refer to the above-mentioned... Figure 4 The records are as described above, so I will not go into detail here.

[0276] Then, refer to Figure 8 In (2), at the second moment after n frames are output, core selection is triggered. In the application scenario of game application A, the frequency limit value remains unchanged at 1. The corresponding load threshold also remains unchanged at 1. However, the thread load changes to 2. Therefore, based on thread load 2 and load threshold 1, core selection is re-selected, and the number of threads may change. Figure 8 As shown in (2), if the thread load of the logic thread is heavier than the thread load of the rendering thread at the second moment, then the logic thread (i.e. the target thread) in the candidate thread will be migrated to the big core to run, and at the same time, the rendering thread in the candidate thread will be migrated to the medium core to run.

[0277] And, reference Figure 8In (4), at the second moment after n frames are output, core selection is triggered. In the application scenario of game application B, the frequency limit value changes to frequency limit value 4, and the corresponding load threshold changes to load threshold 4. However, the thread load does not change and remains at thread load 1. Therefore, based on thread load 1 and load threshold 4, core selection is re-selected, and the threads may also change. If the minimum frequency limit value increases, it may be determined to be a low-load scenario (i.e., the load state is the first state). In this case, not using a large core will not affect performance. Therefore, in order to save power consumption, all candidate threads are migrated to run on medium cores, such as Figure 8 As shown in (4), there is currently no target thread.

[0278] Therefore, it is evident that, in different application scenarios, the candidate threads selected to run on the larger core are all related to the frequency limit and thread load. In other words, for different applications, selecting the target thread and migrating it to the larger core are all related to dynamically changing frequency limits and thread loads.

[0279] In some embodiments, migrating to a large core can be done by binding the target thread to a large core and waiting for the next core selection decision to determine whether to continue running on a large core or migrate from a large core to a medium core.

[0280] Alternatively, the target thread can be migrated to a high-priority core by setting a core selection priority. Specifically, the core selection priority of the high-priority core is set to the highest. This way, when selecting a core for the target thread, it will be prioritized and run on the high-priority core, in descending order of priority. This method of setting core selection priority is more flexible than always binding the target thread to the high-priority core. For example, if the target thread encounters blocking or other abnormal issues after being placed on the high-priority core, the electronic device can temporarily migrate the target thread to a medium-priority core based on the core selection priority, thus ensuring that the target thread will not be blocked after being placed on the high-priority core.

[0281] In some embodiments, the target application may include three or more candidate threads. These three or more candidate threads include a rendering thread and two or more logical threads. These two or more logical threads are the two or more threads that have a wake-up relationship with the rendering thread and have the heaviest thread load related to frame output.

[0282] For scenarios with three or more candidate threads, a migration priority can be pre-defined for each candidate thread based on its actual demand for large cores. This actual demand can be determined through historical load analysis. Then, when core selection is triggered, the two candidate threads with the highest migration priorities can be selected as a group to participate in the selection process.

[0283] If neither of the two selected candidate threads is assigned to a large core, the next group of candidate threads can be selected based on the migration priority to determine whether a candidate thread should be assigned to a large core. Similarly, if there are multiple large cores, multiple groups of candidate threads can be selected according to their migration priority, and the assignment of a candidate thread to a large core can be decided separately for each group.

[0284] For example, if the CPU has only one large core, multiple candidate threads can be selected to participate in the core selection process according to the priority of migration, but only one candidate thread can be selected to be installed on the large core, meaning there is only one target thread. If the CPU has two large cores, multiple candidate threads can also be selected to participate in the core selection process according to the priority of migration, but two candidate threads can be selected to be installed on the large core, meaning there are two target threads.

[0285] In some embodiments, because the rendering thread is the application thread used for frame output in the target application (such as a game application), it is usually the most heavily loaded application thread in the target application. Therefore, the core migration priority of the rendering thread can be set to the highest. This ensures that the rendering thread has priority on large cores, thereby guaranteeing performance.

[0286] Another embodiment of this application provides an electronic device, including: one or more processors and a memory. The memory is coupled to the processor; the memory stores one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device implements the core selection method described in any of the above embodiments.

[0287] Another embodiment of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor in an electronic device, causes the electronic device to implement the core selection method described in any of the above embodiments.

[0288] This application also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps described in the above method embodiments.

[0289] This application also provides a chip system, such as... Figure 9 As shown, the chip system 900 includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 are interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (e.g., a computer's memory). As another example, the interface circuit 902 can be used to send signals to other devices (e.g., the processor 901).

[0290] For example, interface circuit 902 can read instructions stored in memory and send those instructions to processor 901. When the instructions are executed by processor 901, the computer can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

[0291] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0292] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0293] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0294] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0295] If the function of the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0296] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for selecting kernels, characterized in that, The method is applied to an electronic device, the electronic device including a central processing unit (CPU), the core of the CPU including a medium core and a large core; the method includes: Launch the target application; Obtain the frequency limiting values ​​of the mid-core and the large-core, and determine the load threshold based on the frequency limiting values; wherein, the frequency limiting values ​​are dynamically set based on the operating status of the target application and the electronic device; If a target thread exists among the candidate threads and the target thread is running on the medium core, the target thread is migrated from the medium core to the large core; the target thread is determined based on the load threshold and the thread load of the candidate threads; the candidate thread is the application thread of the target application.

2. The method according to claim 1, characterized in that, The application thread includes a rendering thread and at least one logical thread. The rendering thread is the application thread used for frame output in the target application. The logical thread is the application thread that has a wake-up relationship with the rendering thread and is related to frame output. The candidate threads include the rendering thread and the logical thread with the heaviest historical load.

3. The method according to claim 1, characterized in that, The application thread includes a rendering thread and at least one logical thread. The rendering thread is the application thread used for frame output in the target application. The logical thread is an application thread that has a wake-up relationship with the rendering thread and is related to frame output. The method further includes: The candidate threads are selected based on the migration priority of the application threads, and the candidate threads include the two application threads with the highest migration priority; the migration priority is set based on the historical load of the application threads; wherein, if the target thread is not among the selected candidate threads, the candidate threads are reselected based on the migration priority.

4. The method according to any one of claims 1-3, characterized in that, The number of large cores is less than the number of candidate threads, and only one candidate thread runs on a large core.

5. The method according to any one of claims 1-4, characterized in that, The step of obtaining the frequency limiting values ​​of the mid-core and the large-core includes: After the target application outputs frames n times, the frequency limiting values ​​of the medium core and the large core are obtained; n is a positive integer greater than or equal to 1; wherein, the thread load corresponding to the candidate thread is the average of the thread load of n single frames; the n single frame thread loads are thread loads that correspond one-to-one with the n output frames; the single frame thread load is determined after the frame output based on the running time of the candidate thread and the frequency of the core.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: If the candidate thread runs on the large core, the thread load corresponding to the candidate thread is corrected using a correction coefficient; The correction coefficient is the ratio of the first load to the second load. The first load is the thread load when the candidate thread runs on the medium core, and the second load is the thread load when the candidate thread runs on the large core. The candidate thread corresponding to the first load is the same as the candidate thread corresponding to the second load.

7. The method according to claim 6, characterized in that, The method further includes: Before the correction, if the candidate threads on the large core change, the correction coefficients are updated based on the first and second loads corresponding to the changed candidate threads. If the updated correction coefficient is less than the preset first coefficient threshold, the first coefficient threshold is used as the correction coefficient; if the updated correction coefficient is greater than the second coefficient threshold, the second coefficient threshold is used as the correction coefficient; the second coefficient threshold is greater than the first coefficient threshold.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: The load status of the candidate thread is determined based on the load threshold and the thread load of the candidate thread; If the load state is the first state, it is determined that the target thread does not exist among the candidate threads; If the load state is the second state, it is determined that the target thread exists among the candidate threads, and the target thread is the candidate thread corresponding to the largest thread load; the load indicated by the second state is higher than the load indicated by the first state.

9. The method according to claim 8, characterized in that, The method further includes: If the load state is the third state, determine whether there is a device power consumption gain if the candidate thread corresponding to the largest thread load is migrated to run on the large core; the load indicated by the third state is higher than the load indicated by the first state and lower than the load indicated by the second state; When there is a device power gain, the candidate thread corresponding to the largest thread load is selected as the target thread; when there is no device power gain, it is determined that the target thread does not exist among the candidate threads.

10. The method according to claim 9, characterized in that, The load threshold includes a maximum load threshold and a minimum load threshold; determining the load state of the candidate thread based on the load threshold and the thread load of the candidate thread includes: If the maximum value of the thread load corresponding to the candidate thread is less than the minimum load threshold, the load state is determined to be the first state. If the maximum value of the thread load corresponding to the candidate thread is greater than the highest load threshold, the load state is determined to be the second state; If the maximum value of the thread load corresponding to the candidate thread is greater than the minimum load threshold but less than the maximum load threshold, the load state is determined to be the third state.

11. The method according to any one of claims 1-10, characterized in that, The frequency limiting value includes the first maximum frequency limiting corresponding to the mid-core, and the load threshold includes the maximum load threshold; The maximum load threshold util1 is determined using the following expression: util1=smaf_M / fmax_M*ca_M*sa1; Wherein, smaf_M is the first maximum frequency limit; fmax_M is the maximum frequency of the core; ca_M is the maximum computing power of the core; and sa1 is a preset constant.

12. The method according to claim 11, characterized in that, The frequency limiting value also includes a first minimum frequency limit corresponding to the mid-core and a second minimum frequency limit corresponding to the large core; the load threshold also includes a minimum load threshold; The minimum load threshold util2 is determined using the following expression: util2=max(smif_M / fmax_M*ca_M*sa2,smif_B / fmax_B*ca_B*sa2); Wherein, smif_M is the first minimum frequency limit; smif_B is the second minimum frequency limit; fmax_B is the maximum frequency of the large core; ca_B is the maximum computing power of the large core; and sa2 is a preset constant.

13. The method according to claim 9, characterized in that, The determination of whether migrating the candidate thread corresponding to the highest thread load to run on a large core results in a device power consumption gain includes: Calculate the load difference, which is the difference between the thread loads corresponding to the candidate threads; When the absolute value of the load difference is greater than the load difference threshold, a device power consumption gain is determined. When the absolute value of the load difference is less than the load difference threshold, the power consumption gain without devices is determined; wherein the load difference threshold is determined based on the maximum computing power and the number of frequency points of the core.

14. The method according to claim 13, characterized in that, The load difference threshold is determined using the following expression: util3 = ca_M / nf_M * sa3; Wherein, util3 is the load difference threshold; ca_M is the maximum computing power of the core; nf_M is the number of frequency points of the core; and sa3 is a preset coefficient.

15. The method according to claim 9, characterized in that, The determination of whether migrating the candidate thread corresponding to the highest thread load to run on a large core results in a device power consumption gain includes: The power consumption of a first device and the power consumption of a second device are determined. The power consumption of the first device is the power consumption of the device before the candidate thread corresponding to the maximum thread load is migrated to the big core for operation. The power consumption of the second device is the power consumption of the device after the candidate thread corresponding to the maximum thread load is migrated to the big core for operation. The power consumption of the first device and the power consumption of the second device are determined based on a preset energy efficiency table. If the power consumption of the first device is greater than the power consumption of the second device, it is determined that there is a device power consumption gain; If the power consumption of the first device is less than or equal to the power consumption of the second device, then no device power consumption gain is determined.

16. The method according to claim 15, characterized in that, The power consumption P1 of the first device is determined by the following expression: P1 = P_M(fb_M) * uMsum; Wherein, fb_M is the first mid-core frequency before the candidate thread corresponding to the largest thread load is migrated to the big core for operation; P_M(fb_M) is the energy efficiency value corresponding to the first mid-core frequency; uMsum is the total load on the mid-core before migration to the big core for operation; the energy efficiency value corresponding to the first mid-core frequency is determined based on the energy efficiency table.

17. The method according to claim 15 or 16, characterized in that, The power consumption P2 of the second device is determined by the following expression: P2=P_M(fa_M)*(uMsum-uBsum)+P_B(freq_B)*uBsum; Wherein, fa_M is the second intermediate core frequency after the candidate thread corresponding to the largest thread load is migrated to the big core for operation; freq_B is the big core frequency after the candidate thread corresponding to the largest thread load is migrated to the big core for operation; P_M(fa_M) is the energy efficiency value corresponding to the second intermediate core frequency; P_B(freq_B) is the energy efficiency value corresponding to the big core frequency; uBsum is the total load on the big core after migration to the big core for operation; wherein, the energy efficiency value corresponding to the second intermediate core frequency and the energy efficiency value corresponding to the big core frequency are determined based on the energy efficiency table.

18. The method according to claim 17, characterized in that, The first intermediate core frequency, the second intermediate core frequency, and the large core frequency are determined using the following expression: fb_M or fa_M=X / ca_M*fmax_M*C; freq_B = Y / ca_B * fmax_B * C; Where X is the total load on the most heavily loaded intermediate core; Y is the total load on the large core after the candidate thread corresponding to the largest thread load is migrated to run on the large core; ca_M is the maximum computing power of the intermediate core; ca_B is the maximum computing power of the large core; fmax_M is the maximum frequency of the intermediate core; fmax_B is the maximum frequency of the large core; and C is a preset constant.

19. The method according to any one of claims 1-18, characterized in that, The step of migrating the target thread from the medium core to the large core includes: Bind the target thread to the large core; or... A core selection priority is set for the target thread, and a core is selected for the target thread based on the core selection priority; wherein, the large core has the highest core selection priority, and when the large core is running normally, the target thread is migrated to the large core for running based on the core selection priority; when the large core is running abnormally, the target thread is migrated to the medium core for running based on the core selection priority.

20. The method according to claim 8, characterized in that, The method further includes: If the target thread is not among the candidate threads, but a candidate thread is running on the large core, the candidate thread running on the large core will be migrated to the medium core.

21. The method according to any one of claims 1-20, characterized in that, The target applications include game applications.

22. An electronic device, characterized in that, include: One or more processors and a memory, the memory being coupled to the processor; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device causes the core selection method as described in any one of claims 1-21 to be performed.

23. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor of the electronic device, the electronic device performs the core selection method as described in any one of claims 1-21.

24. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor in an electronic device, the electronic device performs the core selection method as described in any one of claims 1-21.

Images