WO2023206693A1 - ***休眠方法及装置、***唤醒方法及装置 - Google Patents

***休眠方法及装置、***唤醒方法及装置 Download PDF

Info

Publication number
WO2023206693A1
WO2023206693A1 PCT/CN2022/095695 CN2022095695W WO2023206693A1 WO 2023206693 A1 WO2023206693 A1 WO 2023206693A1 CN 2022095695 W CN2022095695 W CN 2022095695W WO 2023206693 A1 WO2023206693 A1 WO 2023206693A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
cpu
frequency
wake
tasks
Prior art date
Application number
PCT/CN2022/095695
Other languages
English (en)
French (fr)
Inventor
彭钰
温从洋
邓凯
庄则良
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2023206693A1 publication Critical patent/WO2023206693A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4418—Suspend and resume; Hibernate and awake
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • Embodiments of the present application relate to the technical field of operating systems, and in particular, to a system hibernation method and device, and a system wake-up method and device.
  • electronic devices can control the operating system to enter a sleep state according to different states of the power supply when the operating system does not need to work, so as to save system power consumption.
  • a wake-up type interrupt occurs, the electronic device can wake up the operating system of the device from the hibernation state and resume the running state (also called the wake-up state), so that the system can resume work.
  • the present application provides a system sleep method and device, and a system wake-up method and device.
  • This method can reduce the number of frozen or unfrozen tasks and the number of devices that sleep or wake up, thereby increasing the speed of system sleep and wake-up, reducing the response time of system sleep and wake-up, improving user experience, and increasing standby time.
  • this application provides a system hibernation method.
  • the method includes: in response to receiving a system sleep request, filtering first tasks that are in a blocked state; freezing filtered second tasks that are not in a blocked state; and based on device status information, freezing a first device of a first type.
  • the second task is a task after filtering the first task, and the second task is not in a blocking state (it can also be described as being in a non-blocking state).
  • the second task may be a remaining task after filtering out the first task in a blocked state for all (or part) of the tasks in the operating system.
  • tasks to be frozen can be filtered by traversing tasks.
  • the task status of the filtered task in the blocked state is switched to the running state.
  • the second task that is not in the blocked state can be frozen, then Tasks in blocked state can still be frozen after waking up to ensure the reliability of system hibernation.
  • the first type of device is used to represent devices that do not affect the operation of the CPU.
  • the first type of device may be a plug-in device (referred to as a peripheral device).
  • a preset device list may be configured for the first type of device.
  • hibernating a device can cause the device to stop running, shut down, or power off.
  • the device status information may be generated based on whether the at least one device is in a running state during the operation of the system.
  • This application can detect whether at least one plug-in device is in a running state when the system is running, thereby maintaining the device status of the plug-in device when the system is running.
  • the device state may include a first state or a second state, where the first state is used to indicate that the device is in a running state (such as a startup state, a power-on state, etc.).
  • a device in a running state is also called a device.
  • the second state is used to indicate that the device is not in a running state (such as a closed state, a stopped running state, a power-off state, etc.).
  • a running state such as a closed state, a stopped running state, a power-off state, etc.
  • the device status information generated by the system maintenance may include the device status information of all peripheral devices, or include the device status information of some peripheral devices.
  • the second device when sleeping peripherals, there is no need to hibernate the second device that is not in the running state (also called sleeping) recorded in the device status information. It is only necessary to hibernate the peripherals of the system, except the second device.
  • the peripheral devices other than the second device (the first device mentioned above) are put into hibernation, so that the peripheral devices other than the second device can be stopped running, thereby achieving the effect of hibernating the peripheral devices.
  • the system sleep process reduces the number of sleep peripherals and improves the speed of peripheral sleep.
  • the device status information is data dynamically generated based on whether the detected peripheral device is in a running state during system operation. Therefore, the device status information may only include device status information of some peripheral devices.
  • the peripheral device in which the system sleeps i.e., the first device
  • the peripheral device in which the system sleeps may be a peripheral device in the recorded device status information, or it may be a peripheral device that has not yet been This application does not limit the peripherals recorded in the device status information.
  • the data structure of the device status information may be a linked list.
  • the linked list can be a linked list that records all peripherals, and the device status of detected peripherals can be marked.
  • the linked list can also be two linked lists, one linked list is used to record the peripherals in the running state, and the other linked list is used to record the peripherals not in the running state. This application does not limit this.
  • the task when the system is sleeping, the task can be frozen, and then the device can be hibernated.
  • freezing tasks tasks in a blocked state may not be frozen, thereby reducing the number of frozen tasks and speeding up task freezing.
  • the number of device hibernation can be reduced based on the device status information maintained when the system is running, thereby speeding up the device hibernation process.
  • the overall system sleep speed can be improved and the system sleep process time can be shortened.
  • the response time of the electronic device installed with the system when the system is dormant (such as turning off the screen) can be shortened and the user experience can be improved.
  • the system after the system sleep process is accelerated, the system can enter the sleep state faster, thereby reducing system power consumption and increasing the system's standby time.
  • the method before filtering the first task in a blocked state, the method further includes: when detecting that the system sleep request is a preset sleep request, increasing the working frequency of the CPU to the first task. A frequency; wherein the first frequency is the highest operating frequency of the CPU.
  • the CPU of the system is a multi-core CPU
  • the CPU whose frequency is increased here may be the main core CPU and/or the slave core CPU.
  • the preset sleep request is a sleep request related to user experience.
  • the operating frequency of the CPU can be increased to the highest operating frequency to accelerate the instruction execution speed of the CPU. Then, in response to the system sleep request, the above system sleep is executed.
  • the system hibernation process can be accelerated as a whole (for example, the task freezing process, hibernation device process, etc. can be accelerated) to maximize the user experience.
  • the method before filtering the first task in a blocked state, the method further includes: when detecting that the system sleep request is not a preset sleep request, changing the operating frequency of the CPU to Increase to the second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency, the energy efficiency ratio of the CPU is the highest.
  • the second frequency may be named as the operating frequency with the best energy efficiency ratio of the CPU.
  • the energy efficiency ratio of the CPU is the highest, which can be understood as: when the CPU completes the same amount of instruction execution tasks under different operating frequencies of the CPU, Wherein, when the working frequency of the CPU is the second frequency, the power consumption of the CPU is the lowest.
  • the CPU of the system is a multi-core CPU
  • the CPU whose frequency is increased here may be the main core CPU and/or the slave core CPU.
  • the operating frequency a with the best energy efficiency ratio can be used to indicate that when the operating frequency of the CPU is the operating frequency a, the energy efficiency ratio of the CPU is the highest and the power consumption of the CPU is the lowest.
  • the system sleep request when the system sleep request is not a preset sleep request, it means that the system sleep request is not related to the user experience, and the user does not care about the speed of the system sleep process.
  • this application provides a frequency modulation strategy for the CPU used in the system sleep or wake-up scenario.
  • the frequency modulation strategy includes increasing the CPU frequency to the highest operating frequency when the system sleep request or system wake-up request is a preset request. Frequency, when the system sleep request or system wake-up request is not a preset request, the CPU frequency is increased to the operating frequency with the best energy efficiency ratio.
  • filtering the first task in the blocked state includes: filtering the first task in the blocked state among the second type tasks; wherein the second type of task is an operation Tasks in the system other than system tasks.
  • tasks in the system may include user-mode tasks and kernel-mode tasks.
  • user mode tasks can include common tasks and system service tasks (also a system task). Kernel state tasks are all system tasks.
  • the method further includes: sending a freeze signal to the second type of task, where the freeze signal is used to instruct the task to freeze.
  • the embodiment of the present application may send a freeze signal to all ordinary tasks, where ordinary tasks include ordinary tasks in a blocked state. So although the task in the blocked state does not need to be frozen, it can still send a freeze signal to the task in the blocked state. Even if the task in the blocked state is in the non-blocked state before sleeping the peripheral, the task can still process the freeze signal. , to freeze the task that is no longer in the blocked state, ensuring that the blocked task can still be frozen after resuming operation, improving the reliability of system hibernation.
  • the method further includes: putting the first device into a blocked state.
  • the third task that is not in the frozen state among the two tasks is saved to the first data structure; the third task in the first data structure is cyclically traversed, and the task status of the traversed third task is detected; in the When it is detected in the first data structure that the task status of the third task is the frozen state, the third task in the frozen state is deleted from the first data structure; when the third task is detected in the first data structure When the task status of the three tasks is not the frozen state, the loop continues to traverse the first data structure until the first data structure is empty.
  • the second task includes a third task.
  • a task of the second type of tasks that is not in a blocking state may process the freeze signal to freeze the task.
  • the application can detect the task status of the second task to save the third task that has not been frozen (in an unfrozen state) to the first data structure.
  • the tasks in the first data structure can be cyclically traversed to detect the task status, so as to delete the tasks in the frozen state from the first data structure. Then, as the tasks in the non-blocking state (for example, the second task) are frozen As the progress progresses, there are fewer and fewer tasks in the first data structure.
  • the first data structure only saves unfrozen tasks, thereby avoiding redundant checking of task status of a large number of frozen tasks, improving the traversal efficiency of unfrozen tasks, and thereby accelerating the task freezing process.
  • the first data structure no longer includes any tasks, indicating that all tasks in the non-blocking state have been frozen, and the task freezing process ends.
  • the third task in the first data structure can be cyclically traversed within a preset time period, thereby preventing the third task in the first data structure from being frozen for a long time and affecting the system sleep speed.
  • the CPU of the system is a multi-core CPU
  • the multi-core CPU includes a main core CPU and at least one slave core CPU
  • the first device of the first type is hibernated based on the device status information.
  • the method further includes: before powering off the first slave core CPU, retaining the timers and tasks on the first slave core CPU without migrating them to the second CPU; wherein, the second CPU It is the second slave core CPU or the main core CPU; the at least one slave core CPU includes the first slave core CPU, or further includes the second slave core CPU.
  • the timer task on the slave core CPU is in a blocked state and is added to the blocked task list. After the timer expires, the task corresponding to the timer can send an interrupt to the slave core CPU. However, since the slave core CPU has been offline, the task corresponding to the timer has not been migrated to other running CPUs, so that after the system enters the kernel, it will no longer receive interrupts initiated by tasks of the offline slave core CPU. As a result, tasks that are awakened after blocking will not be executed, ensuring that blocked tasks are not frozen and correct.
  • the hibernation of the first device of the first type based on the device status information includes: filtering the second device among the first type of devices based on the device status information. to determine the first device of the first type; and perform hibernation on the first device.
  • peripherals that have been dormant for example, in a closed state
  • the remaining peripherals after filtering can be put to sleep, thereby reducing the number of dormant devices. Number of devices.
  • the method further includes: during the operation of the system, when it is detected that the third device of the first type is in a running state, recording the device status of the third device. Or update to the first state to generate or update the device status information; wherein the first state is information indicating that the third device is in a running state; during the operation of the system, it is detected that the When the fourth device of the first type is not in a running state, record or update the device status of the fourth device to a second status to generate or update the device status information; wherein the second status is Information used to indicate that the fourth device is not in a running state; the device state is the first state or the second state; wherein the at least one device includes: the third device and/or the Describe the fourth device.
  • the S3 state means that only necessary devices such as memory are powered to ensure that data is not lost. Other components are turned off, and the system's power consumption is extremely low.
  • the detected peripheral 1 when the system is running, the detected peripheral 1 is in a running state. Then, when the device status of peripheral 1 is not recorded in the data structure (such as a linked list) corresponding to the device status information, this application can record the device status of peripheral 1 as running status in the data structure, thereby generating the device status. information.
  • the data structure such as a linked list
  • the detected peripheral 2 is in a running state. Then, when the device status of peripheral 2 (such as stopped running status) is recorded in the data structure (such as linked list) corresponding to the device status information, this application can change the device status of peripheral 2 from stopped in the data structure. The running status is updated to the running status, thereby updating the device status information.
  • the device status of peripheral 2 such as stopped running status
  • the data structure such as linked list
  • the system by recording or updating the detected equipment in the running state and/or the detected equipment not in the running state into the above-mentioned data structure (such as a linked list) when the system is running, This allows device status information to be generated or updated.
  • the system is sleeping, based on the devices in the second state (not running state) recorded in the device status information, the number of sleeping devices can be reduced and the speed of device sleeping can be improved.
  • the method further includes: recording or updating the first device in the device status information.
  • the device state is the second state.
  • the system can perform the system sleep process. For example, during the system sleep process, based on the device status information, after the first device (such as some peripheral devices) is put to sleep, all peripheral devices can be put to sleep. Then, in order to ensure the accuracy of the device status information, the system can The status information of the sleeping peripheral device during the hibernation process is recorded or updated into the device status information, so that the device status of the first device in the device status information is a non-running state (for example, the second state).
  • a non-running state for example, the second state
  • this application provides a system wake-up method.
  • the method includes: in response to receiving a system wake-up request, waking up a first device of a first type based on device status information; wherein the device status information includes: a device status of at least one device of the first type, the The device status is information used to indicate whether the device is in a running state; the first device is different from the second device, wherein the second device is a device in the running state among the at least one device; for a frozen state The first task is unfrozen; wherein the first task is not in a blocked state when frozen.
  • the device status information may be generated based on whether the at least one device is in a running state during the operation of the system.
  • This application can detect whether at least one plug-in device is in a running state when the system is running, thereby maintaining the device status of the plug-in device when the system is running.
  • the device state may include a first state or a second state, where the first state is used to indicate that the device is in a running state (such as a startup state, a power-on state, etc.).
  • a device in a running state is also called a device.
  • the second state is used to indicate that the device is not in a running state (such as a closed state, a stopped running state, a power-off state, etc.).
  • a device in a sleep state when the device is not in a running state, it is also called a device in a sleep state.
  • the device is in the running state, which is also called the device in the awake state.
  • the device when the system wakes up, the device can be woken up and then the task can be unfrozen.
  • the number of device wake-ups can be reduced based on the device status information maintained during system operation, thereby speeding up the device wake-up process.
  • unfreezing tasks tasks in the blocked state do not need to be unfrozen, thereby reducing the number of unfrozen tasks and speeding up task unfreezing.
  • the overall system wake-up speed can be improved and the system wake-up process can be shortened.
  • the response time of system wake-up (such as turning on the screen) of the electronic device installed with the system can be shortened and the user experience can be improved.
  • the method before waking up the first device of the first type based on the device status information, the method further includes: after the CPU comes online, after detecting that the system wakeup request is a preset When a wake-up request is made, the operating frequency of the CPU is increased to a first frequency; wherein the first frequency is the highest operating frequency of the CPU.
  • the frequency of the main core CPU can be increased according to the frequency increase strategy of this application.
  • the frequency of the slave core CPU can be increased according to the frequency increase strategy of this application.
  • the preset wake-up request is a wake-up request related to user experience.
  • the operating frequency of the CPU can be increased to the highest operating frequency to accelerate the instruction execution speed of the CPU. Then, in response to the system wake-up request, the above-mentioned system wake-up is performed.
  • the system wake-up process can be accelerated as a whole (for example, the task unfreezing process, device wake-up process, etc. can be accelerated) to maximize the user experience.
  • the method before waking up the first device of the first type based on the device status information, the method further includes: after the CPU comes online, after detecting that the system wakeup request has not When a preset wake-up request is made, the operating frequency of the CPU is increased to a second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency , the CPU has the highest energy efficiency ratio.
  • the system wake-up request when the system wake-up request is not a preset wake-up request, it means that the system wake-up request is not related to the user experience, and the user does not care about the speed of the system wake-up process.
  • the system wake-up request can be The operating frequency of the CPU is adjusted to the above-mentioned operating frequency with the best energy efficiency ratio to save system power consumption to the greatest extent.
  • this application provides a frequency modulation strategy for the CPU used in the system sleep or wake-up scenario.
  • the frequency modulation strategy includes increasing the CPU frequency to the highest operating frequency when the system sleep request or system wake-up request is a preset request. Frequency, when the system sleep request or system wake-up request is not a preset request, the CPU frequency is increased to the operating frequency with the best energy efficiency ratio.
  • the method further includes: restoring the frequency modulation strategy of the CPU to the original frequency modulation strategy; wherein, the original frequency modulation strategy is the frequency modulation strategy of the CPU before receiving the system wake-up request.
  • this application does not limit the original frequency modulation strategy of the CPU.
  • the original frequency modulation strategy is the frequency modulation strategy of the CPU before entering the frequency increase operation of the present application in the system sleep or wake-up process.
  • the original frequency modulation policy may be a fixed frequency modulation policy, that is, the working frequency of the CPU is adjusted to the fixed working frequency configured by the policy.
  • the original frequency modulation strategy can also be a dynamic frequency modulation strategy, that is, the working frequency of the CPU is flexibly adjusted according to the tasks running on the CPU.
  • the first task is a task that is not in a blocked state among the second type of tasks, wherein the second type of task is a task in the operating system other than system tasks. .
  • unfreezing tasks there is no need to unfreeze system tasks (including system service tasks in user mode and system tasks in kernel mode). Only tasks that are not blocked among ordinary tasks need to be unfrozen. There are a large number of system tasks, and there is no need to unfreeze system tasks, which can greatly increase the speed of task unfreezing, thereby shortening the system wake-up time.
  • the waking up the first device of the first type based on the device status information includes: filtering the second device among the first type of devices based on the device status information. to determine the first device of the first type; and wake up the first device.
  • peripherals that have been awakened for example, in a running state
  • the remaining peripherals after filtering can be awakened, thereby reducing the number of awakened peripherals. Number of devices.
  • the method further includes: during the operation of the system, when it is detected that the third device of the first type is in a running state, recording the device status of the third device. Or update to the first state to generate or update the device status information; wherein the first state is information indicating that the third device is in a running state; during the operation of the system, it is detected that the When the fourth device of the first type is not in a running state, record or update the device status of the fourth device to a second status to generate or update the device status information; wherein the second status is Information used to indicate that the fourth device is not in a running state; the device state is the first state or the second state; wherein the at least one device includes: the third device and/or the Describe the fourth device.
  • the system by recording or updating the detected equipment in the running state and/or the detected equipment not in the running state into the above-mentioned data structure (such as a linked list) when the system is running, This allows device status information to be generated or updated.
  • the system wakes up based on the device in the first state (running state) recorded in the device status information, the number of devices to be woken up can be reduced and the speed of device wakeup can be improved.
  • the method further includes: recording or updating the first device in the device status information.
  • the device state is the first state.
  • the system can For example, during the system wake-up process, based on the device status information, after waking up the first device (such as some peripherals), all peripherals can be woken up. Then, in order to ensure the accuracy of the device status information, the system can The status information of the peripheral device woken up during the wake-up process is recorded or updated into the device status information, so that the device status of the first device in the device status information is a running status (for example, the first status).
  • the present application provides a system hibernation device.
  • the system sleep device includes: a filtering module, used to filter the first task in a blocked state in response to receiving a system sleep request; a freezing module, used to freeze the filtered second task that is not in a blocked state; a hibernation device A module configured to hibernate a first device of a first type based on device status information; wherein the device status information includes: a device status of at least one device of the first type, and the device status is used to indicate whether the device Information in a running state; the first device is different from a second device, wherein the second device is a device among the at least one device that is not in a running state.
  • the system sleep device further includes: a first frequency increasing module, configured to increase the operating frequency of the CPU to the first frequency when detecting that the system sleep request is a preset sleep request. ; Wherein, the first frequency is the highest operating frequency of the CPU.
  • the system sleep device further includes: a second frequency increasing module, configured to increase the operating frequency of the CPU to A second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency, the energy efficiency ratio of the CPU is the highest.
  • a second frequency increasing module configured to increase the operating frequency of the CPU to A second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency, the energy efficiency ratio of the CPU is the highest.
  • the filtering module is specifically configured to filter the first task in a blocked state among the second type of tasks; wherein the second type of task is a task other than system tasks in the operating system. other tasks.
  • system hibernation device further includes: a signal sending module, configured to send a freezing signal to the second type of task, where the freezing signal is used to instruct the task to freeze.
  • the system hibernation device further includes: a saving module, configured to save the third task that is not in the frozen state among the second tasks to the first data structure; and a traversal module, configured to Loop through the third task in the first data structure, and detect the task status of the traversed third task; delete module, used to detect the task status of the third task in the first data structure When it is in the frozen state, delete the third task in the frozen state from the first data structure; the traversal module is also used to detect that the task status of the third task is not in the first data structure. When in the frozen state, continue to loop through the first data structure until the first data structure is empty.
  • the CPU of the system is a multi-core CPU
  • the multi-core CPU includes a main core CPU and at least one slave core CPU.
  • the system hibernation device further includes: a reservation module, configured to Before the slave core CPU is powered off, the timers and tasks on the first slave core CPU are retained without migrating to the second CPU; wherein the second CPU is the second slave core CPU or the master core CPU ;
  • the at least one slave core CPU includes the first slave core CPU, or further includes the second slave core CPU.
  • the dormant device module is specifically configured to: based on the device status information, filter the second device among the first type of devices to determine the first type of the second device. A device; putting the first device to sleep.
  • the system hibernation device further includes: a device status management module, configured to: during the operation of the system, when it is detected that the third device of the first type is in a running state, The device status of the third device is recorded or updated to a first status to generate or update the device status information; wherein the first status is information indicating that the third device is in a running status; in During the operation of the system, when it is detected that the fourth device of the first type is not in a running state, the device status of the fourth device is recorded or updated to a second status to generate or update the device status. information; wherein the second state is information indicating that the fourth device is not in a running state; the device state is the first state or the second state; wherein the at least one device includes : the third device and/or the fourth device.
  • a device status management module configured to: during the operation of the system, when it is detected that the third device of the first type is in a running state, The device status of the third device is recorded or updated to a first status to generate
  • the device status management module is further configured to record or update the device status of the first device to the second status in the device status information.
  • this application provides a system wake-up device.
  • the system wake-up device includes: a wake-up device module, configured to wake up a first device of the first type based on device status information in response to receiving a system wake-up request; wherein the device status information includes: at least The device status of a device, the device status is information indicating whether the device is in a running state; the first device is different from the second device, wherein the second device is in the running state of the at least one device The device; the unfreezing module is used to unfreeze the first task in the frozen state; wherein the first task is not in the blocked state when frozen.
  • the system wake-up device further includes: a first frequency increasing module, configured to increase the operating frequency of the CPU after the CPU comes online and detects that the system wake-up request is a preset wake-up request. Increase to the first frequency; wherein the first frequency is the highest operating frequency of the CPU.
  • a first frequency increasing module configured to increase the operating frequency of the CPU after the CPU comes online and detects that the system wake-up request is a preset wake-up request. Increase to the first frequency; wherein the first frequency is the highest operating frequency of the CPU.
  • the system wake-up device further includes: a second frequency increasing module, configured to increase the frequency of the CPU when it is detected that the system wake-up request is not a preset wake-up request after the CPU comes online.
  • the operating frequency is increased to a second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency, the energy efficiency ratio of the CPU is the highest.
  • the system wake-up device further includes: a frequency increase releasing module, configured to restore the frequency modulation strategy of the CPU to the original frequency modulation strategy; wherein the original frequency modulation strategy is when receiving the The frequency modulation strategy of the CPU before the system wake-up request.
  • the first task is a task that is not in a blocked state among the second type of tasks, wherein the second type of task is a task in the operating system other than system tasks. .
  • the wake-up device module is specifically configured to: based on the device status information, filter the second device among the first type of devices to determine the first type of the second device. A device; waking up the first device.
  • the system wake-up device further includes: a device status management module, configured to: when the third device of the first type is detected to be in a running state during the operation of the system, The device status of the third device is recorded or updated to a first status to generate or update the device status information; wherein the first status is information indicating that the third device is in a running status; in During the operation of the system, when it is detected that the fourth device of the first type is not in a running state, the device status of the fourth device is recorded or updated to a second status to generate or update the device status. information; wherein the second state is information indicating that the fourth device is not in a running state; the device state is the first state or the second state; wherein the at least one device includes : the third device and/or the fourth device.
  • a device status management module configured to: when the third device of the first type is detected to be in a running state during the operation of the system, The device status of the third device is recorded or updated to a first status to generate or update the device status
  • the device status management module is further configured to record or update the device status of the first device to the first status in the device status information.
  • the present application provides a system hibernation device.
  • the system hibernation device includes one or more interface circuits and one or more processors; the interface circuit is used to receive signals from a memory and send the signals to the processor, where the signals include computer data stored in the memory. Instructions; when the processor executes the computer instructions, the processor can implement the system hibernation method in any of the above embodiments.
  • the effect of the system hibernation device in this embodiment is similar to the effect of the system hibernation method in each of the above embodiments, and will not be described again here.
  • this application provides a system wake-up device.
  • the system wake-up device includes one or more interface circuits and one or more processors; the interface circuit is used to receive signals from a memory and send the signals to the processor, where the signals include computer data stored in the memory. Instructions; when the processor executes the computer instructions, the processor can implement the system wake-up method in any of the above implementations.
  • the present application provides a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program.
  • the computer program When the computer program is run on a computer or processor, it causes the computer or processor to perform the system hibernation method in any of the above embodiments, or causes the computer or processor to perform any of the above.
  • a system wake-up method in an implementation manner.
  • the effect of the computer-readable storage medium in this embodiment is similar to the effect of the system sleep method or the system wake-up method in each of the above embodiments, and will not be described again here.
  • the present application provides a computer program product.
  • the computer program product includes a software program.
  • the software program is executed by a computer or a processor, the system sleep method or the system wake-up method in any of the above embodiments is executed.
  • Figure 1 is a schematic diagram illustrating the process of system sleep and wake-up in traditional technology
  • Figure 2a is a schematic diagram of the microkernel architecture of an exemplary host
  • Figure 2b is a schematic diagram of an exemplary system software architecture
  • Figure 2c is an exemplary interaction diagram of each module
  • Figure 3a is a schematic diagram of an exemplary system hibernation process
  • Figure 3b is a schematic diagram of an exemplary system wake-up process
  • Figure 4a is a schematic diagram of an exemplary frequency increasing process
  • Figure 4b is a graph of test data exemplarily shown
  • Figure 5a is a schematic diagram of an exemplary freezing task process
  • Figure 5b is a schematic diagram of an exemplary freezing task process
  • Figure 6a is a schematic diagram of an exemplary process of device status management
  • Figure 6b is a process schematic diagram of an exemplary hibernation device
  • Figure 6c is a schematic diagram of an exemplary process of waking up the device
  • Figure 7a is a schematic structural diagram of a device provided by an embodiment of the present application.
  • Figure 7b is a schematic structural diagram of a device provided by an embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of a chip provided by an embodiment of the present application.
  • a and/or B can mean: A exists alone, A and B exist simultaneously, and they exist alone. B these three situations.
  • first and second in the description and claims of the embodiments of this application are used to distinguish different objects, rather than to describe a specific order of objects.
  • first target object, the second target object, etc. are used to distinguish different target objects, rather than to describe a specific order of the target objects.
  • multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.
  • ACPI Advanced Configuration and Power Interface
  • S3 Suspend to RAM (STR for short, also called sleep state), only maintains power supply for necessary devices such as memory to ensure that data is not lost, other components are turned off, and the system's power consumption is extremely low.
  • S4 Suspend to Disk (STD for short), the main power of the system is turned off, but the hard disk is still charged and can be woken up. It is a more power-saving power state than S4.
  • electronic devices can control the operating system to enter S3 (also called sleep state) when the operating system does not need to work according to different states of the power supply, so as to save system power consumption.
  • S3 also called sleep state
  • the electronic device can wake up the device's operating system from the hibernation state and restore it to S0 (also called the running state, or wake-up state), so that the system can resume work.
  • FIG. 1 is a schematic diagram illustrating the process of system hibernation and wake-up under the Linux kernel architecture in traditional technology.
  • the sleep process is as follows: First, the user mode initiates a sleep request, and the sleep request module can receive the sleep request. Then, the freezing task module can freeze tasks based on the hibernation request, specifically freezing user-mode tasks and kernel-mode tasks. For example, freezing a process can be understood as the kernel setting the status of all processes in the process list to the stopped state and saving the context of all processes. For example, freezing a kernel-mode task can set the status of a kernel-mode task (such as a system task) to a stopped state. Then, the sleep peripheral module can call the suspend (suspend) callback function of the registered device to sleep the peripherals in the order of registration.
  • the sleep peripheral module can call the suspend (suspend) callback function of the registered device to sleep the peripherals in the order of registration.
  • the offline slave core module can hibernate the slave core CPU to take the slave core CPU offline.
  • the core equipment offline module can control the core equipment to stop running and take the core equipment offline.
  • the hibernation main core module can control the main core CPU to enter the sleep state, so that the main core CPU sleeps.
  • the wake-up process is as follows: the operating system in a dormant state is awakened by an interrupt or other event as shown in Figure 1.
  • the main core wake-up module can start the main core CPU to wake up the main core.
  • the Online Core Device module then starts the core device to bring the core device online.
  • the online slave core module can start the slave core CPU to bring the slave core CPU online.
  • the wake-up peripheral module then enables the peripheral to wake up the peripheral.
  • the unfreezing task module can start the user mode task and the kernel mode task in the stopped state to unfreeze the task and make the task in the running state. At this point, the wake-up process is completed.
  • the process of freezing tasks takes a long time, and the more tasks that need to be frozen, the longer the process takes; in addition, during the process of sleep and wake-up, the hibernation device
  • the process of (including peripherals) and waking up the device (including peripherals) also takes a long time, and the more hardware devices in the electronic device, the longer it takes.
  • the system sleep wake-up scheme in the related art because the process of freezing tasks and hibernating devices and waking up devices takes a long time, it may cause the system hibernation process and wake-up process to take too long, and the sleep and wake-up speed is slow.
  • this application provides a sleep and wake-up method for an operating system, which can increase the speed of the sleep and wake-up process of the operating system through CPU frequency increase, and reduce the time consuming of the sleep and wake-up process. And by reducing the number of frozen tasks and reducing the number of sleep and wake-up devices, shorten the sleep and wake-up process of the operating system, thereby shortening the response time of the sleep and wake-up (such as turning on and off the screen) of electronic devices to improve the user experience. , and reduce the power consumption overhead of the system. Moreover, the speed of system sleep and wake-up processes is increased, which can extend the standby time of electronic devices.
  • the electronic device to which the sleep-awakening operating system of this application is installed can be a cellular phone, a tablet, a wearable device or an Internet of Things device, or a Cockpit Domain Controller (CDC). ), etc., this application does not limit this.
  • CDC Cockpit Domain Controller
  • the CPU is adjusted from a higher-level active state to an inactive state, which is hibernation; when a signal is received, the system is re-run, which is wake-up.
  • Each embodiment of the present application takes the system sleep process as entering the S3 state and the system wake-up process as entering the S0 state as examples for description.
  • Power consumption refers to the amount of energy consumed per unit time, in W.
  • Frequency increase refers to increasing the running frequency of the CPU, thereby improving the performance of the CPU.
  • Freeze the task Set the status of the task to the stopped state to pause the running of the task.
  • the frozen task cannot generate data and will not interact with any modules.
  • the task status of the frozen task is frozen.
  • Unfreeze the task Restore the status of the task from the frozen state to the running state, so that the task can continue to execute from the task state at the time of being frozen.
  • the unfrozen task can generate data and interact with other modules.
  • task 1 is frozen at time t1, so that all data and operations of task 1 are suspended at time t1.
  • task 1 is unfrozen at time t2, all data and operations of task 1 can continue to be executed at time t2.
  • time t2 is after time t1.
  • the tasks described in various embodiments of this application may include, but are not limited to: threads or processes.
  • Core device a device that can affect the operation of the CPU.
  • the core device can include hardware devices located inside the CPU.
  • Plug-in devices devices that do not affect the operation of the CPU.
  • the system can include a device list of plug-in devices.
  • external devices may include, but are not limited to, mice, keyboards, printers, etc.
  • Figure 2a is an exemplary schematic diagram of the microkernel architecture of the host of the present application
  • Figure 2b can be a schematic diagram of the software architecture of the system of the present application.
  • the host of this application can be divided into a multi-layer architecture, including an application layer, a framework service layer, a kernel layer and a hardware layer.
  • the application layer and the framework service layer can be implemented in the user state
  • the kernel layer and hardware layer can be implemented in the kernel state.
  • the application layer may include at least one application program, and application 1 to application n are exemplarily shown here.
  • the application layer may receive user input.
  • the framework service layer (also known as the microkernel service layer, or the user-mode basic service of the microkernel) may include but is not limited to: a power management module (also known as a power management service), a driver framework module, etc.
  • a power management module also known as a power management service
  • driver framework module etc.
  • only two service modules in the framework service layer are shown as an example.
  • the service framework layer may also include more service modules, and there is no limitation here.
  • the operating system of the embodiment of the present application is implemented under the microkernel architecture.
  • Each functional module involved in the framework service layer can be transplanted from the kernel mode to the user mode under the microkernel architecture to implement the functions in an application manner. Provide users with corresponding services.
  • the power management module can be used for power management, etc.
  • the driver framework module can be used to run drivers for various hardware devices.
  • the kernel layer may include a kernel processing module and a kernel interrupt subsystem.
  • the hardware layer may include a multi-core CPU, and the multi-core CPU may include a master core CPU and at least one slave core CPU (one slave core CPU is exemplarily shown here).
  • the hardware layer can also include core devices and plug-in devices. For the definitions of the two types of devices, please refer to the above and will not be repeated here.
  • tasks in the operating system can be divided into user-mode tasks and kernel-mode tasks.
  • the user-mode task is a task running in the user-mode (such as a process, a thread, etc.).
  • user-mode tasks may include common tasks and user-mode system service tasks.
  • ordinary tasks tasks created by users triggering operations, such as tasks created by users triggering operations on applications located in the application layer in user mode or services located in the framework service layer in Figure 2a.
  • a user triggers an operation of playing music on a music application (such as an application in the application layer of Figure 2a), and the system creates a task of playing music in response to the user operation, which is a normal task.
  • a music application such as an application in the application layer of Figure 2a
  • user-mode system service tasks system tasks triggered by each service module in the framework service layer shown in Figure 2a (rather than triggered by the user). For example, it is used to display the mobile desktop interface.
  • the kernel state task is a system task running in the kernel state.
  • the kernel layer overhead is low.
  • system tasks may include system service tasks in user mode and system tasks in kernel mode.
  • the application layer, framework service layer, kernel layer, and hardware layer shown in Figure 2a do not constitute specific limitations on the device.
  • the device may include more or fewer levels than shown, and each layer may include more or fewer components than shown, or some components may be combined or separated. Certain parts, or different arrangements of parts.
  • the various layers, various components shown in Figure 2a may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and/or application specific integrated circuits.
  • Figure 2b is a schematic diagram illustrating the sleep and wake-up process of the operating system of the present application.
  • the left half of Figure 2b is a schematic diagram of the operating system hibernation process, and the right half of Figure 2b is a schematic diagram of the operating system wake-up process.
  • the power management module (also called the sleep wake-up management module) may include but is not limited to: the CPU frequency increase maintenance module, the fast freezing task module, and the fast sleep device module shown in Figure 2b. , slave core frequency increase maintenance module, quick wake-up device module, unfreeze task module, optionally including CPU frequency increase release module.
  • the core processing module may include but is not limited to: the slave core offline module, the dormant core device module, and the master core offline module shown in Figure 2b. , the main core online module, the wake-up core device module, and the slave core online module.
  • the system shown in Figure 1 in the related art is applied to an operating system under a kernel architecture.
  • the system shown in Figure 2b of this application can not only be applied to an operating system under a kernel architecture (such as the Linux operating system), but can also be applied to Figure 2a
  • the operating system under the microkernel architecture shown below will be described later by taking the system of the present application applied to the operating system under the microkernel architecture as an example.
  • the principles are similar. I won’t go into details one by one.
  • the system of this application has added the following software modules: CPU frequency increase maintenance module, slave core frequency increase maintenance module, fast freezing task module, fast sleep device module, and fast wake-up device module.
  • a CPU frequency boost release module is also included.
  • the above-mentioned modules may constitute the main difference from the solution shown in Figure 1.
  • other modules in Figure 2b are also different from the corresponding modules in Figure 1. The specific differences will be elaborated below.
  • the CPU frequency increase maintenance module and the slave core frequency increase maintenance module can implement a precise CPU frequency increase mechanism. Specifically, they can be used to obtain a system sleep or wake-up request and determine whether the request is a preset request (default sleep request or Preset wake-up request), if the request is a preset request (preset sleep request or preset wake-up request), it means that the request is strongly related to the user experience, so the CPU (main core CPU, and/or, slave core CPU ) to the highest operating frequency to increase the instruction execution speed of the CPU, thereby accelerating the completion of the system sleep or wake-up process; on the contrary, if the request is not a default request, it means that the request is not strongly related to the user experience, then The CPU operating frequency can be increased to the operating frequency with the best energy efficiency ratio to maintain the sleep and wake-up process with the lowest CPU power consumption.
  • the above precise CPU frequency increase mechanism can be regarded as a CPU frequency increase strategy provided by this application.
  • the CPU frequency increase strategy can be triggered during system sleep or system wake-up.
  • the preset sleep request is a sleep request related to user experience.
  • the default wake-up request is a wake-up request related to user experience.
  • the request related to user experience may be a system hibernation request in a scenario where the user wants the system hibernation (or wake-up) process to be faster and shorter in time.
  • the operating frequency of the CPU when the operating frequency of the CPU is the operating frequency a with the best energy efficiency ratio, the energy efficiency ratio of the CPU is the highest. It can be understood that when the CPU completes the same amount of instruction execution tasks at different operating frequencies, when the operating frequency of the CPU is the operating frequency a, the power consumption of the CPU is the lowest. Therefore, the operating frequency a can be named the operating frequency with the best energy efficiency ratio of the CPU.
  • the quick freezing task module can implement a quick freezing task mechanism. Under this mechanism, there is no need to wait for blocking tasks, optionally no need to freeze system tasks, and the number of frozen tasks is reduced to achieve quick freezing of tasks, thereby accelerating system hibernation. process.
  • the quick freeze task module filters tasks
  • first filter the system tasks to obtain ordinary tasks and then filter the tasks in the blocking state among the ordinary tasks, and only freeze the ordinary tasks in the non-blocking state to speed up task freezing.
  • the quick freezing task module can also directly identify ordinary tasks, and then filter the tasks in the blocking state among the ordinary tasks, so that only the ordinary tasks in the non-blocking state are frozen to speed up task freezing.
  • the fast sleep device module and the fast wake-up device module can be combined with the runtime sleep wake-up mechanism to manage and record the status (sleep state or wake-up state) of the external device when the system is running. Then when the system needs to sleep or wake up, the number of nodes of the plug-in device to be slept or awakened can be reduced based on the recorded status of the plug-in device, so as to quickly sleep and wake up the device, thus accelerating the system sleep and wake-up process.
  • the CPU frequency increase release module can be used to restore the frequency modulation strategy of the CPU to the original frequency modulation strategy after unfreezing the task; wherein the original frequency modulation strategy is that before receiving the system wake-up request, the CPU FM strategy.
  • the CPU here is a CPU whose frequency has been increased using the frequency increase strategy of this application during the system sleep or wake-up process. It can be a main core CPU or a slave core CPU, and this application does not limit it.
  • this application does not limit the original frequency modulation strategy of the CPU.
  • the original frequency modulation strategy is the frequency modulation strategy of the CPU before entering the frequency increase operation of the present application in the system sleep or wake-up process.
  • the original frequency modulation policy may be a fixed frequency modulation policy, that is, the working frequency of the CPU is adjusted to the fixed working frequency configured by the policy.
  • the original frequency modulation strategy can also be a dynamic frequency modulation strategy, that is, the working frequency of the CPU is flexibly adjusted according to the tasks running on the CPU.
  • the various modules and communication connection relationships in the system of the present application shown in Figure 2b are only an example.
  • the system of the present application may have more or fewer modules than shown in the figure, and two or more modules may be merged and combined. modules, or can have different module configurations.
  • the various modules shown in Figure 2b may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and/or application specific integrated circuits.
  • FIG. 2c is an interaction diagram of some components in FIG. 2a during the process of executing system sleep or system wake-up.
  • Figure 2c shows the interaction between different modules with a unidirectional arrow. In specific applications, there may be two-way interactive communication between different modules, which will not be described again here.
  • Embodiment 1 system sleep process:
  • Step 11 Receive the system sleep request.
  • the power management module may receive a system sleep request from the application layer or kernel interrupt subsystem.
  • the system sleep request may be a preset event triggered by the system or a preset event triggered by the user at the application layer.
  • the system sleep method of this application can be applied to system sleep scenarios of electronic devices such as mobile phones, motor vehicles, and other electronic devices. This application does not limit this.
  • the power management module may receive the user-triggered system sleep request from the application layer.
  • the system sleep request is a preset sleep request that is strongly related to the user experience. It can be understood that the default sleep request that is strongly related to user experience is not limited to the examples here.
  • the system of this application can be applied to CDC in a motor vehicle scenario. If the motor vehicle does not move for a long time, and the user does not perform any operations on the display screen of the motor vehicle for a long time, the system can trigger a system sleep request to hibernate the motor vehicle. system.
  • the system sleep request here is not a preset sleep request that is strongly related to user experience.
  • CDC can be divided into instrument domain and entertainment domain.
  • the preset sleep request may include a sleep request related to the display of the instrument domain or the entertainment domain.
  • the power management module may receive the system sleep request from the interrupt subsystem.
  • the system of this application can be applied to a mobile phone. If the screen of the mobile phone is turned on for a long time and the mobile phone does not receive any input triggered by the user, the interrupt subsystem periodically sends a system sleep request to the power management module, so that the power management module switches from the interrupt subsystem to the power management module.
  • the system receives a system-triggered system sleep request. Among them, if the user does not care about the speed of the sleep process, then the system sleep request is not a preset sleep request that is strongly related to the user experience.
  • a system sleep request is a default sleep request that is strongly related to user experience does not limit the system sleep request triggered by the user at the application layer to be a default sleep request, nor does it limit the reason.
  • the system sleep request automatically issued by the interrupt subsystem must not be a preset sleep request. Whether the system sleep request is a preset sleep request has no direct correlation with the triggering object of the system sleep request.
  • the CPU frequency increase maintenance module in the power management module can receive a system sleep request sent by the application layer, or the CPU frequency increase maintenance module can receive a system sleep request sent by the kernel interrupt subsystem.
  • the power management module shown in Figure 2c can determine the target frequency to which the CPU is to be increased based on whether the system sleep request is a preset sleep request. (The highest operating frequency or the operating frequency with the best energy efficiency ratio).
  • the multi-core CPU can be divided into multiple groups of CPUs.
  • an 8-core CPU may include two groups of 4-core CPUs, where the operating frequencies of the CPUs in a group of 4-core CPUs are close to each other. Then, when the CPU frequency increase maintenance module determines the target frequency to which the CPU frequency is to be increased, the target frequency can be determined separately for the working frequency of each group of CPUs, and the target frequencies of the same group of CPUs are the same. For example, the target frequency is the highest operating frequency corresponding to the set of CPUs, or the operating frequency with the best energy efficiency ratio.
  • the operating frequency of each single-core CPU can be controlled independently. Then, when the CPU frequency increase maintenance module determines the target frequency to which the CPU frequency is to be increased, the CPU frequency increase maintenance module can adjust the frequency of each CPU.
  • the single-core CPU determines the target frequency separately, and the target frequencies of each core CPU are independent of each other. For example, the target frequency of a single-core CPU is the highest operating frequency of the single-core CPU, or the operating frequency with the best energy efficiency ratio.
  • the multi-core CPU includes a master core CPU and at least one slave core CPU.
  • This application does not impose restrictions on the offline order and frequency increase sequence of different slave core CPUs, but the slave core CPUs are all in The main core CPU goes offline before it goes offline.
  • the system of this application can first increase its working frequency before taking the CPU offline, so that the CPU can freeze the CPU running at a higher working frequency. tasks to speed up the system hibernation process and shorten the duration of the hibernation process.
  • the power management module shown in Figure 2c (for example, the CPU frequency increase maintenance module shown in Figure 2b) can store the CPU to be increased and the target frequency to which the CPU is to be increased. Information is notified to the kernel processing module.
  • the core processing module can send instructions to the main core CPU to increase the operating frequency of the main core CPU and/or the slave core CPU to the corresponding target frequency.
  • the CPU to be boosted may include a master core CPU and/or a slave core CPU, which is not limited in this application.
  • the master core CPU can increase the frequency of the slave core CPU.
  • the core processing module may send a first instruction to the main core CPU, so that the main core CPU increases the working frequency of the slave core CPU to the corresponding target frequency.
  • the core processing module can also send a second instruction to the main core CPU, so that the main core CPU increases the working frequency of the main core CPU to the corresponding target frequency.
  • the first instruction and the second instruction may be the same or different, and this application does not limit this.
  • the master core CPU can increase the frequency of the slave core CPU.
  • the power management module (such as the CPU frequency increase maintenance module shown in Figure 2b) can also notify the information of the CPU to be increased and the target frequency to which the CPU is to be increased.
  • the core device driver module shown in Figure 2a enables the core device driver module to increase the operating frequency of the main core CPU and/or the slave core CPU to the corresponding target frequency.
  • the master core CPU can also increase the working frequency of the slave core CPU to a corresponding target frequency.
  • the core device driver module may include a driver for the core device.
  • Step 13 the task is frozen.
  • the power management module shown in Figure 2c can, based on the quick freeze task mechanism, freeze the tasks in the operating system (for example, the tasks in the operating system). All tasks) to filter.
  • the power management module can filter common tasks in a blocked state and filter system tasks (including user-mode system service tasks and kernel-mode system tasks) for all tasks in the operating system.
  • the power management module can use the kernel processing module to control the main core CPU and/or the slave core CPU to freeze ordinary tasks executed on the corresponding CPU that are not blocked, thereby reducing the number of frozen tasks, thereby achieving Quick freeze of tasks.
  • the power management module can be based on a quick freezing task mechanism. , for tasks in the operating system (such as all tasks in the operating system), filter tasks in a blocked state.
  • the power management module can control the main core CPU and/or the slave core CPU with the help of the kernel processing module to freeze tasks executed on the corresponding CPU that are not in a blocked state. During this process, there is no need to freeze tasks in a blocked state, and the number of frozen tasks can be reduced, thereby achieving rapid freezing of tasks.
  • Step 14 Hibernate non-core devices.
  • the power management module shown in Figure 2c (such as the fast sleep device module shown in Figure 2b) can be combined with the runtime sleep wake-up mechanism to enter the system sleep shown in Figure 2b or Before the system wake-up process, manage whether non-core devices (such as plug-in devices) are in the sleep state or wake-up state. Therefore, when entering the system hibernation process shown in Figure 2b, the power management module does not need to traverse the plug-in devices in the hibernation state, and can reduce the number of calls to the first callback function for the hibernation device, thus speeding up the process of hibernation. .
  • one device may correspond to a first callback function for sleeping the device.
  • the peripheral module shown in Figure 2c can include the driver of the corresponding external device.
  • the power management module when the power management module sleeps the traversed external device, the power management module can call the peripheral module to hibernate the corresponding plug-in device.
  • the power management module may call the first callback function of the driver of the corresponding device to hibernate the corresponding plug-in device.
  • Step 15 offline the slave core CPU.
  • the power management module shown in Figure 2c can notify the kernel processing module (such as the slave core offline module shown in Figure 2b) to Offline at least one slave core CPU.
  • the kernel processing module such as the slave core offline module shown in Figure 2b
  • the information that the power management module notifies the kernel processing module is not limited to the examples here, and may also include more information, which is not limited here.
  • the kernel processing module can freeze all kernel-state tasks (for example, kernel-state threads) running on the slave-core CPU, and control the slave-core CPU to perform operations such as going offline.
  • kernel-state tasks for example, kernel-state threads
  • Step 16 Hibernate the core device.
  • the core processing module shown in Figure 2c may sleep (for example, shut down) the core device.
  • Step 17 Offline the main core CPU.
  • the kernel processing module shown in Figure 2c can remove all kernel state tasks (such as kernel state threads) running on the main core CPU. ) to freeze and control the main core CPU to go offline and other operations.
  • kernel state tasks such as kernel state threads
  • the operating system can be hibernated through the above-mentioned steps 11 to 17, and the CPU frequency can be increased, so that the increased frequency CPU can be used to process the instructions of the hibernation process to accelerate the system hibernation process; and
  • freezing tasks there is no need to freeze tasks that are in a blocked state, which can reduce the number of task freezes.
  • you can filter system tasks so that only ordinary tasks that are not in a blocked state are frozen, which can further reduce the number of task freezes. This speeds up task freezing; and the device status can be managed based on device status changes during system operation.
  • the duration of the system sleep process can be shortened and the system sleep speed can be improved to improve user experience and reduce power consumption.
  • Embodiment 2 system wake-up process:
  • Step 21 Receive the system wake-up request.
  • the power management module may receive a system wake-up request from the application layer or kernel interrupt subsystem.
  • the system sleep request may be a preset event triggered by the system or a preset event triggered by the user at the application layer.
  • the system wake-up method of this application can be applied to system wake-up scenarios of electronic devices such as mobile phones, motor vehicles, and other electronic devices. This application does not limit this.
  • the power management module may receive a system wake-up request sent by the application layer, or the power management module may receive a system wake-up request sent by the kernel interrupt subsystem.
  • the power management module may receive the user-triggered system wake-up request from the application layer.
  • the system wake-up request is a preset wake-up request that is strongly related to the user experience.
  • the system of this application can be applied to CDC in a motor vehicle scenario.
  • the user presses the start engine button of the motor vehicle, and the power management module can receive the system wake-up request triggered by the user to Wake up the vehicle's operating system.
  • the system wake-up request here is a preset wake-up request that is strongly related to user experience.
  • the power management module may receive the system wake-up request from the interrupt subsystem.
  • the system of this application can be applied to mobile phones.
  • the mobile phone system can periodically send heartbeat instructions to wake up the system to perform related operations.
  • the heartbeat instructions here do not belong to pre-conditions that are strongly related to user experience. Assume a wake-up request, because the user does not care about the speed of the wake-up process. Moreover, this awakening process is imperceptible to the user.
  • a system wake-up request is a default wake-up request that is strongly related to user experience does not limit the system wake-up request triggered by the user at the application layer to be a default wake-up request, nor does it limit the reason.
  • the system wake-up request automatically issued by the interrupt subsystem must not be a preset wake-up request. Whether the system wake-up request is a preset wake-up request has no direct correlation with the triggering object of the system wake-up request.
  • Step 22 Online the main core CPU.
  • the power management module may notify the kernel processing module of the received system wake-up request.
  • the main core online module in the core processing module can receive a system wake-up request (such as an interrupt signal used to wake up the system).
  • the kernel processing module can control the main core CPU to perform operations such as going online.
  • Step 23 Wake up the core device.
  • the core processing module shown in Figure 2c (for example, the wake-up core device module shown in Figure 2b) can wake up the core device (for example, start running).
  • Step 24 bring the slave core CPU online.
  • the core processing module shown in Figure 2c (for example, the slave core online module shown in Figure 2b) can go online for at least one slave core CPU.
  • Step 25 increase the CPU frequency.
  • the power management module shown in Figure 2c may be based on the system wake-up request received from the application layer or the kernel interrupt subsystem. , whether it is a preset wake-up request, to determine the target frequency to which the online slave core CPU is to be boosted (the highest operating frequency or the operating frequency with the best energy efficiency ratio).
  • the number of online slave core CPUs is at least one.
  • the power management module can separately determine the target frequency to be increased to for each slave core CPU. (The highest operating frequency or the operating frequency with the best energy efficiency ratio), or a common target frequency to be increased to (the highest operating frequency or the operating frequency with the best energy efficiency ratio) can be determined for multiple slave core CPUs.
  • the target frequency is the highest operating frequency of the corresponding slave core CPU.
  • the target frequency is the corresponding slave core CPU. The operating frequency of the core CPU with the best energy efficiency ratio.
  • the working frequency of the online slave core CPU can be increased so that the slave core CPU can wake up the non-core device at a higher working frequency. And unfreeze tasks to speed up the system wake-up process and shorten the duration of the wake-up process.
  • the power management module shown in Figure 2c (for example, the slave core frequency increase maintenance module shown in Figure 2b) can be used to configure the CPU to be increased and the target frequency to which the CPU is to be increased.
  • the information is notified to the kernel processing module.
  • the core processing module can send instructions to the main core CPU to increase the operating frequency of the corresponding slave core CPU to the corresponding target frequency.
  • the master core CPU can increase the frequency of the slave core CPU.
  • the core processing module may send a first instruction to the main core CPU, so that the main core CPU increases the working frequency of the slave core CPU to a corresponding target frequency.
  • the power management module (such as the slave core frequency increase maintenance module shown in Figure 2b) can also notify the CPU to be increased and the target frequency to which the CPU is to be increased to.
  • the core device driver module shown in 2a enables the core device driver module to increase the operating frequency of the corresponding slave core CPU to the corresponding target frequency.
  • step 25 is similar to the principle of step 12 in the hibernation process, and will not be described again here.
  • Step 26 Wake up non-core devices.
  • the power management module shown in Figure 2c (such as the quick wake-up device module shown in Figure 2b) can be combined with the runtime sleep wake-up mechanism to enter the system sleep shown in Figure 2b or Before the system wake-up process, manage whether non-core devices (such as plug-in devices) are in the sleep state or wake-up state. Therefore, when entering the system wake-up process shown in Figure 2b, the power management module does not need to traverse the external devices in the wake-up state, and can reduce the number of calls to the second callback function used to wake up the device, thus accelerating the process of waking up the device. .
  • one device may correspond to a second callback function for waking up the device.
  • the peripheral module shown in Figure 2c can include the driver of the corresponding external device.
  • the power management module when the power management module wakes up the traversed external device, the power management module can call the peripheral module to wake up the corresponding plug-in device.
  • the power management module may call the second callback function of the driver of the corresponding device to wake up the corresponding plug-in device.
  • Step 27 unfreeze the task.
  • the power management module shown in Figure 2c (such as the unfreezing task module shown in Figure 2b) can unfreeze the tasks in the frozen state through the kernel processing module to restore the corresponding tasks. of operation.
  • the task in the frozen state here is not in the blocked state when frozen.
  • the tasks in the frozen state are ordinary tasks.
  • the task to be unfrozen here may be the task frozen in step 13 in Embodiment 1.
  • step 28 cancel the CPU frequency increase.
  • the power management module shown in Figure 2c (such as the CPU frequency increase release module shown in Figure 2b) can restore the frequency modulation strategy of the CPU to the original frequency modulation strategy after unfreezing the task;
  • the original frequency modulation strategy is the frequency modulation strategy of the CPU before receiving the system wake-up request.
  • the CPU here is a CPU whose frequency has been increased using the frequency increase strategy of this application during the system sleep or wake-up process. It can be a main core CPU or a slave core CPU, and this application does not limit it.
  • this application does not limit the original frequency modulation strategy of the CPU.
  • the original frequency modulation strategy is the frequency modulation strategy of the CPU before entering the frequency increase operation of the present application in the system sleep or wake-up process.
  • the original frequency modulation policy may be a fixed frequency modulation policy, that is, the working frequency of the CPU is adjusted to the fixed working frequency configured by the policy.
  • the original frequency modulation strategy can also be a dynamic frequency modulation strategy, that is, the working frequency of the CPU is flexibly adjusted according to the tasks running on the CPU.
  • the power management module may notify the core processing module shown in FIG. 2c of the frequency to be adjusted to by the slave core CPU. Then the kernel processing module can notify the main core CPU to adjust the working frequency of the slave core CPU, or the kernel processing module can notify the slave core CPU to self-adjust the working frequency of the slave core CPU. This application does not limit this .
  • the operating system can be woken up through the above-mentioned steps 21 to 28, and the CPU frequency can be increased, so that the increased frequency CPU can be used to process instructions for the wake-up process to accelerate the system wake-up process; and
  • the device status can be managed based on device status changes.
  • the number of traversals of devices to be woken up can be reduced, thus accelerating the device wake-up process.
  • the duration of the system wake-up process can be shortened and the system wake-up speed can be improved to improve user experience and reduce power consumption.
  • Figure 3a is a schematic diagram illustrating a system hibernation process.
  • Figure 3a takes the CDC of a motor vehicle as an application scenario.
  • the CDC is divided into an instrument domain and an entertainment domain.
  • the instrument domain is a microkernel architecture (such as the microkernel architecture shown in Figure 2a).
  • the system of this application can run on embedded platforms.
  • the system sleep process may include the following steps:
  • S501 The power management module receives the system sleep request and processes it.
  • the power management module can refer to the implementation process shown in Figure 4a to implement S501 through a precise CPU frequency increase mechanism.
  • the power management module's implementation process of the precise CPU frequency increase mechanism may include:
  • the power management module receives the system sleep request.
  • the power management module determines whether the system sleep request is a preset request.
  • the power management module may receive a user-triggered system hibernation request from the application layer to hibernate the operating system of the motor vehicle.
  • the system sleep request here is a preset sleep request that is strongly related to user experience.
  • the power management module can receive a system sleep request sent by the interrupt subsystem shown in Figure 2c to hibernate the vehicle system.
  • the system sleep request here is not a preset sleep request that is strongly related to user experience.
  • the system sleep request may be in the form of an event.
  • the power management module may configure a first preset event representing the preset sleep request.
  • the power management module may switch to the first preset event.
  • the process can be transferred to S104.
  • the power management module when the power management module detects that the system sleep request is a preset request, it may determine that the target frequency to be increased for the CPU is the highest operating frequency.
  • the preset request may include a preset sleep request.
  • the power management module can determine the CPU to be boosted and the target frequency to which the CPU is to be boosted, here This is the maximum operating frequency of the CPU.
  • the power management module can be configured with the highest operating frequency of each single-core CPU or each group of CPUs (including multi-core CPUs).
  • S104 When the power management module detects that the system sleep request is not a preset request, it may determine that the target frequency to be increased for the CPU is an operating frequency with the best energy efficiency ratio.
  • the power management module can receive a system sleep request sent by the interrupt subsystem shown in Figure 2c to hibernate the vehicle system. .
  • the power management module detects that the system sleep request here does not belong to the preset sleep request that is strongly related to user experience, and can determine the CPU to be boosted and the target frequency to which the CPU is to be boosted to which is the best energy efficiency ratio of the CPU. working frequency.
  • the optimal energy efficiency ratio operating frequency of each CPU is strongly related to the hardware of the CPU.
  • the operating frequency with the best energy efficiency ratio of each CPU can be determined based on the power consumption test data of the specific chip platform CPU at each operating frequency.
  • FIG. 4b is an exemplary graph showing test data of the operating frequency of the CPU and the current of the battery.
  • the operating frequency with the best energy efficiency ratio is the power consumption inflection point frequency shown by the circle in Figure 4b (for example, here is 918MHz).
  • the working frequency of the best energy efficiency ratio of each CPU in the system can be a priori data
  • the power management module can be configured with the working frequency of the best energy efficiency ratio of each single-core CPU or each group of CPUs (including multi-core CPUs).
  • the power management module increases the frequency of the CPU through the device driver module.
  • the device driver module in Figure 3a may include the core device driver module shown in Figure 2a.
  • the power management module can notify the device driver module of the information of the CPU to be increased and the target frequency to which the CPU is to be increased (the highest operating frequency or the operating frequency with the best energy efficiency ratio).
  • the core device driver module enables the core device driver module to increase the operating frequency of the main core CPU and/or the slave core CPU to the corresponding target frequency.
  • the system of the present application can increase the working frequency of the CPU to its highest working frequency to ensure system sleep to the greatest extent.
  • the user experience of the process when the system sleep request is not related to the user experience (for example, the system sleep request is not a preset sleep request), the system of this application can adjust the CPU working frequency to the working frequency with the best energy efficiency ratio, To save CPU power consumption to the greatest extent.
  • the power management module freezes common tasks through the kernel processing module.
  • the power management module may implement S503 by quickly freezing the task mechanism with reference to the implementation process shown in Figure 5a and Figure 5b.
  • the power management module's implementation process of the quick freezing task mechanism may include the following steps:
  • the power management module traverses common tasks and sends a freeze signal to the common tasks.
  • the power management module can traverse system tasks in the system for filtering, and only traverse ordinary tasks without traversing system tasks (which can include user-mode system service tasks and kernel-mode system tasks). And send a freeze signal to the traversed ordinary tasks, so that every ordinary task in the system can receive the freeze signal to freeze the ordinary tasks.
  • the power management module does not need to filter system tasks, but only needs to filter tasks in a blocked state (including system tasks and ordinary tasks), which can accelerate the task freezing process.
  • a kernel architecture such as a Linux operating system
  • the power management module does not need to filter system tasks, but only needs to filter tasks in a blocked state (including system tasks and ordinary tasks), which can accelerate the task freezing process.
  • Other processes for freezing tasks are similar to the processes for freezing tasks described in various embodiments of this application, and will not be described again here.
  • normal tasks and system tasks are two types of tasks, which can be distinguished and identified through task identifiers.
  • the ordinary task may optionally mark the ordinary task as being in a frozen state.
  • the ordinary task can freeze itself when the ordinary task is not in a blocking state.
  • the ordinary task can send a freezing instruction to the CPU, and the CPU executes the freezing instruction to freeze the ordinary task, so that the state (eg running state) of the ordinary task is updated to the frozen state.
  • a normal task when a normal task receives a freeze signal, the normal task is writing data. Then, after the ordinary task completes the operation of writing data, the ordinary task can then send a freeze instruction to the CPU to freeze the ordinary task.
  • S202 The power management module traverses the common tasks and checks the task status of the common tasks.
  • the power management module may continue to traverse all common tasks in the system and check the task status of the traversed common tasks.
  • the power management module determines whether the task status is a blocking state.
  • the power management module executes S204.
  • the power management module adds the common task in the blocked state to the blocked task linked list.
  • a task in a blocked state indicates that the task is waiting to run. If the task in a blocked state is not in a running state, then in order to shorten the duration of the frozen task, the system of this application does not need to freeze ordinary tasks in a blocked state. .
  • the power management module can also filter common tasks in a blocked state without saving them in a data structure (such as the above-mentioned blocked task linked list).
  • the power management module can implement a task freezing filter.
  • the power management module can use the task freezing filter to filter tasks in a blocked state among ordinary tasks to speed up the task freezing process.
  • the power management module may add filtered tasks in a blocked state to a blocked task linked list (a type of linked list).
  • the system of this application can filter the tasks in the blocked state without judging whether the blocked tasks are in the frozen state, and does not need to freeze the tasks in the blocked state, thereby greatly improving the overall efficiency of the frozen tasks. , and speed up the process of freezing tasks.
  • the power management module can send a freeze signal to all ordinary tasks. Then the tasks in the blocked state among the ordinary tasks can also receive the freeze signal. Then if before entering the step of hibernating non-core devices (such as peripherals), the The status of a blocked task is switched to a non-blocking state. Since the task has received the freeze signal, the task can first process the freeze signal to put the task into the frozen state, thereby preventing the blocked task from switching to a non-blocking state. Afterwards, the task is not frozen and affects system hibernation.
  • non-core devices such as peripherals
  • the system switches to a non-blocking state (such as waking up) before the system sleeps the non-core device (such as before entering S504 in Figure 3a), so that A situation that causes an originally blocked task to be run.
  • a non-blocking state such as waking up
  • the kernel processing module will not migrate the timer (timer) on the slave core CPU and the tasks on the slave core CPU to other online CPUs.
  • the slave core CPU since the slave core CPU has been offline, the task corresponding to the timer has not been migrated to other running CPUs, so that after the system enters the kernel, it will no longer receive interrupts initiated by tasks of the offline slave core CPU. As a result, tasks that are awakened after blocking will not be executed, ensuring that blocked tasks are not frozen and correct.
  • the power management module may check the task status of the task in the blocked task list and determine whether there is a running state in the blocked task list.
  • Task For example, if a task in the blocked task list is in the blocked state, before being offline from the core CPU, the task is awakened and switches from the blocked state to the running state. Although the blocked task has received the freeze signal in advance, the blocked task is still running, resulting in a task that fails to freeze after waking up in the blocked task list.
  • the system hibernation process can be re-executed (for example, return to S501 in Figure 3a, so that the power management module re-executes the system hibernation process. Receive system hibernation request for processing and subsequent steps).
  • the system can freeze and continue to execute the step of offline the slave core CPU in Figure 3a.
  • this embodiment can be used as a solution to handle exceptions and ensure the reliability of system hibernation.
  • the power management module first traverses the common tasks and sends a freeze signal to the common tasks. Then, the power management module filters the tasks in the blocked state among the common tasks. (Here added to the linked list). In other embodiments, the power management module may also first filter common tasks for tasks in a blocked state, and add the tasks in a blocked state to the linked list. The power management module can then traverse ordinary tasks (including tasks in the blocking task list) to send freeze signals. This application does not place any restrictions on the execution order between the steps of filtering tasks in a blocked state and the steps of sending freeze signals to ordinary tasks.
  • the power management module After S203, if the power management module detects that the task status is not blocked, the power management module can execute S205.
  • S205 The power management module determines whether the task status of the task that is not in the blocked state is in the frozen state.
  • the power management module can determine whether the common task has been frozen for a common task that is in a non-blocking state (for example, the task status is not a blocking state).
  • the power management module After S205, the power management module detects a task that is not in a blocked state (for example, the task status is not blocked), and the task status of the task is a frozen state, then it goes to S202, and the power management module continues to traverse the tasks of the next ordinary task. state.
  • a blocked state for example, the task status is not blocked
  • the task status of the task is a frozen state
  • the power management module can continue to traverse the task status of the next common task to evaluate the traversed task status of the blocking state. Filter the tasks, or judge whether the traversed tasks in the non-blocking state are in the frozen state.
  • the power management module After S205, if the power management module detects a task that is not in a blocked state and the task status of the task is not in a frozen state, the power management module executes S206.
  • the common task traversed by the power management module is neither in the blocked state nor in the frozen state, which means that after the freezing signal is sent to the common task through the above S201, the common task has not processed the freezing signal to perform task freezing. .
  • the ordinary task when the ordinary task receives the freeze signal, it is performing a data writing operation. Then, the ordinary task is still running before the data writing operation is completed. Or, the CPU is in a busy state, so that the CPU does not execute the normal task that has received the freeze signal and sends the freeze instruction to the CPU.
  • the power management module can add the ordinary task that is not blocked and not frozen to the unfrozen task list (a kind of linked list).
  • the unfrozen task list is different from the blocked task list.
  • the unfrozen task linked list can be used to cache ordinary tasks that are not in a frozen state and are not in a blocking state.
  • the blocked task linked list can be used to cache ordinary tasks in a blocked state.
  • the power management module executes the process of Figure 5a
  • the power management module completes the task status traversal of the common task (for example, the traversal process of S202 in Figure 5a ends), as shown in Figure 5b
  • the power management module The implementation process of the quick freezing task mechanism can continue to include the following steps:
  • S301 The power management module loops through the unfrozen task list and checks the task status.
  • the power management module can cycle through the unfrozen task list and check the task status within a preset time period, thereby preventing tasks in the unfrozen task list from being unfrozen for a long time and affecting the system sleep speed.
  • the power management module determines whether the task status is a frozen state.
  • the power management module detects that the task status is frozen, and then proceeds to S303.
  • S303 The power management module deletes the frozen task from the unfrozen task list.
  • S301 can be executed in a loop until the unfrozen task list is empty, that is, all ordinary tasks in the non-blocking state have been frozen and are in the frozen state.
  • the power management module can add the traversed normal tasks that are non-blocking and have not yet been frozen to the unfrozen task list. After the power management module traverses the task status of all ordinary tasks once, the power management module may cyclically traverse the task status of the tasks in the unfrozen task chain until all non-blocking tasks in the unfrozen task chain have been frozen. Among them, when the power management module loops through the unfrozen task list, and when it is traversed that the task in the unfrozen task list is in a frozen state, the power management module can delete the task from the unfrozen task list.
  • the power management module checks the status of the task. When the task is in a frozen state, the efficiency of the traversal check process is greatly improved, which can speed up the task freezing efficiency.
  • the power management module waits for a preset time.
  • the power management module proceeds to execution S301, so that the power management module continues to traverse the next task in the unfrozen task list until the unfrozen task list is empty, ending the process.
  • the power management module can wait for a preset time (for example, 10 milliseconds) to delay the preset time. After the duration, execute S301 again. Then, within the preset time delay of the power management module, the CPU executing the instructions of the power management module can be idle, so that the CPU can execute the freezing instructions of the tasks in the unfrozen task list to freeze the tasks.
  • a preset time for example, 10 milliseconds
  • the preset time period can be flexibly configured according to the application scenario, and is not limited to the example of 10 milliseconds.
  • the unit of the preset duration may be milliseconds.
  • S304 is mainly to ensure the reliability of system hibernation. In actual application scenarios, after S302, S303 can be executed, and S304 rarely exists.
  • the system of this application can filter system tasks (including system service tasks in user mode and system tasks in kernel mode) during the system sleep process, and only freeze ordinary tasks in user mode.
  • system tasks including system service tasks in user mode and system tasks in kernel mode
  • the number of driver-related system tasks is relatively large, about 200.
  • filtering system tasks and freezing only common tasks you can significantly reduce the number of frozen tasks.
  • some system tasks serve ordinary tasks. After the ordinary tasks are frozen, these system tasks can no longer run, resulting in some system tasks not being scheduled. Then when freezing tasks, filtering system tasks can reduce freezing operations on tasks that have not been scheduled and reduce unnecessary task freezing operations.
  • system tasks are used to perform subsequent operations of system hibernation, such as hibernating devices, offline CPU, etc., so these system tasks do not need to be frozen. Therefore, under the microkernel architecture, when the system is sleeping, the slave core CPU can be offline. Then the tasks on the slave core CPU will stop executing, leaving only the system tasks running on the master core CPU (for example, for offline slaves). core CPU). Then when the execution phase of the system sleep process enters the kernel state, the system tasks on the slave CPU will no longer be scheduled.
  • the system of this application does not need to freeze system tasks, but only needs to freeze ordinary tasks, which can reduce the number of frozen tasks.
  • the system of this application can adopt the highest priority guarantee of the stop machine mechanism, which can avoid remaining tasks in the system (such as driver-related system tasks) after the core CPU goes offline. Execution stability issues (such as deadlock, etc.).
  • S504 The power management module hibernates the external device through the device driver module.
  • FIG. 6a illustrates an implementation process of the runtime sleep wake-up mechanism implemented by the power management module.
  • the power management module can implement S504 through the process of sleeping the plug-in device shown in Figure 6b in conjunction with the runtime sleep wake-up mechanism implemented in Figure 6a.
  • the device driver module may include the peripheral module shown in FIG. 2a for sleeping or waking up the external device.
  • the power management module's implementation process of the runtime sleep wake-up mechanism may include:
  • S401 can be executed when the power management module needs to periodically traverse the external device.
  • S401 can be executed when the power management module needs to detect the status of the external device. This avoids adding steps to periodically or regularly detect the operating status of the external device, thereby saving signaling overhead.
  • the power management module can generate two linked lists after powering on.
  • Linked list 1 is a hibernated linked list, which is used to cache information about plug-in devices in a dormant state (this information is used to identify plug-in devices, such as device identification).
  • Linked list 2 is an awakened linked list, which is used to cache information about plug-in devices in a running state (this information is used to identify plug-in devices, such as device identification).
  • the initialized linked list 1 and linked list 2 are both empty linked lists.
  • the power management module may record the sequential dependency relationship between the external devices in linked list 1 and linked list 2, for example, using device serial numbers to represent the sequential dependency relationship between the devices.
  • the device serial number of device A is 1, and the device serial number of device B is 2.
  • the device ID of device A is A
  • the device ID of device B is B.
  • the operation of device A depends on device B, when the system wakes up, device B is first woken up, and then device A is put to sleep. Then in the awakened linked list, the device serial number of device B is 1, and the device serial number of device A is 2. Among them, the device ID of device A is A, and the device ID of device B is B.
  • the identification information of each dormant plug-in device is stored in the linked list 1, the identification information can be sorted and stored according to the device serial number.
  • the identification information of each awakened plug-in device is stored in the linked list 2, the information can be sorted and stored according to the device serial number.
  • S402 when the power management module detects that the external device is in a running state, S402 may be executed.
  • the power management module calls a callback function of the plug-in device for waking up.
  • the power management module detects whether the dormant linked list includes the identification information of the plug-in device.
  • the power management module detects that the dormant linked list does not include the identification information of the plug-in device, and then proceeds to S405.
  • S405 The power management module writes the identification information of the plug-in device into the awakened linked list.
  • the power management module detects that the hibernated linked list includes the identification information of the plug-in device, and then proceeds to S404.
  • S404 The power management module transfers the identification information of the plug-in device from the dormant linked list to the awakened linked list.
  • the power management module when the system is running, if the power management module detects that any plug-in device is running, it can call the callback function for waking up the plug-in device in the peripheral module to wake up the plug-in device.
  • the power management module can also record the identification information of the plug-in device to the awakened linked list. For example, when the identification information of the plug-in device is not recorded in the dormant linked list, the identification information of the plug-in device can be written into the awakened linked list. For example, when the identification information of the plug-in device has been recorded in the hibernated linked list, the identification information of the plug-in device can be transferred from the hibernated linked list to the awakened linked list.
  • the power management module can sort the positions of the plug-in devices in the wake-up linked list according to the device serial number of each plug-in device, so that the order dependency relationship of each plug-in device can be determined based on the position of each plug-in device in the wake-up linked list. , to perform peripheral sleep.
  • S406 when the power management module detects that the external device is not in a running state, S406 may be executed.
  • the power management module calls the callback function for sleep of the plug-in device.
  • the power management module detects whether the awakened linked list includes the identification information of the plug-in device.
  • the power management module detects that the awakened linked list does not include the identification information of the plug-in device, and then proceeds to S409.
  • S409 The power management module writes the identification information of the plug-in device into the hibernated linked list.
  • the power management module detects that the awakened linked list includes the identification information of the plug-in device, and then proceeds to S408.
  • the power management module transfers the identification information of the plug-in device from the awakened linked list to the dormant linked list.
  • the power management module when the system is running, if the power management module detects that any plug-in device is not running, it can call the sleep callback function of the plug-in device in the peripheral module to hibernate the plug-in device.
  • the power management module can also record the identification information of the plug-in device to the dormant linked list. For example, when the identification information of the plug-in device is not recorded in the awakened linked list, the identification information of the plug-in device can be written into the dormant linked list. For example, when the identification information of the plug-in device has been recorded in the awakened linked list, the identification information of the plug-in device can be transferred from the awakened linked list to the dormant linked list.
  • the power management module can sort the positions of the plug-in devices in the hibernated linked list according to the device serial number of each plug-in device, so that the order dependency relationship of each plug-in device can be determined based on the position of each plug-in device in the hibernated linked list. , to wake up peripherals.
  • the power management module when the power management module receives the system hibernation request and executes the stage of hibernating peripheral devices in the system hibernation process, as shown in Figure 6b, when starting to hibernate the external device, the power management module can traverse the awakened linked list, and based on the dependency order between the external devices in the awakened linked list (i.e., the above-mentioned sequential dependency), the callback functions for sleeping of the external devices are sequentially called to shut down the running external devices to hibernate the peripherals. .
  • the power management module puts the peripheral to sleep by calling the sleep callback function of the plug-in device, then the peripheral device is in the sleep state, then the device identification of the peripheral device can be written into the hibernated linked list, or the The device identification of the peripheral is transferred from the awakened list to the dormant list. This ensures the integrity of the data recorded in the dormant linked list or the awakened linked list.
  • the power management module does not need to traverse the dormant plug-in devices and call the callback function of the plug-in device for hibernation, but only needs to For external plug-in devices (such as plug-in devices in running state), calling the corresponding callback function for sleep can greatly reduce the number of calls to the callback function for sleep of the peripheral device, and there is no need to hibernate the peripheral device that has been dormant. operation, thereby increasing the speed of hibernating peripherals.
  • the implementation process of the runtime sleep wake-up mechanism by the power management module may be partially different from the solution in Figure 6a.
  • the power management module can be initialized to generate a linked list 3 after the host is powered on. After the host is powered on, the power management module can store the identification information of all plug-in devices connected to the host (or other information that can be used to identify plug-in devices). information), and in this linked list 3, the status information (sleep state or wake-up state) of each plug-in device can be marked.
  • the device being in a sleep state may mean that the device is not in a running state (for example, a shutdown state).
  • a device that is awake means that the device is in a running state.
  • this embodiment can maintain all plug-in devices in one linked list, and can achieve two linked lists (for example, the above-mentioned dormant linked list and awakened linked list) have the same effect, that is, when the system is running, the sleep or wake-up status of the plug-in device is recorded, so that when entering the system sleep or wake-up process, other than the dormant plug-in device can be recorded.
  • the status (sleep state or wake-up state) of the peripheral device can be updated to the linked list 3.
  • the power management module can generate the linked list 3 when the operating system is started and when the device is initialized, including the identifiers of all plug-in devices sorted by device serial numbers.
  • the power management module can mark the status of the plug-in device in the linked list 3 as the wake-up state according to the plug-in device that has been started, and mark the status of the plug-in device that has not been started in the linked list 3. Marked for hibernation.
  • the power management module can check whether the external device is running. For example, the power management module may perform the above checking steps when the power management module needs to periodically traverse the external device. Alternatively, when the power management module needs to detect the status of the external device, the power management module can perform the above checking steps. This avoids adding steps to periodically or regularly detect the operating status of the external device, thereby saving signaling overhead.
  • the power management module After the power management module detects that the status of the plug-in device is running or not, it can determine whether to update the status of the corresponding plug-in device in linked list 3 based on the detection result of the status of the plug-in device.
  • device 1 (a peripheral) is marked as sleeping in linked list 3.
  • the power management module detects that device 1 is in the running state. Then the power management module can change the status of device 1 in linked list 3 from sleeping. The status is updated to the awake state (or running state).
  • the power management module can call the callback function for waking up the driver of the device 1 to wake up the device 1 .
  • device 1 is marked as awake in linked list 3.
  • the power management module detects that device 1 is in the running state, and the power management module does not need to update the status of device 1 in linked list 3.
  • device 1 is marked as awake in linked list 3.
  • the power management module detects that device 1 is in the off state. Then the power management module can update the status of device 1 in linked list 3 from the awake state to the dormant state. .
  • the power management module can call the callback function for sleep on the driver of the device 1 to sleep the device 1 .
  • the power management module after the power management module receives the system sleep request and in the system sleep process, it reaches the stage of hibernating peripheral devices, and when starting to hibernate the external device, the power management module can traverse the above example Linked list 3 to determine at least one plug-in device that is in the awake state. And based on the corresponding sequential dependency relationship of at least one plug-in device, the callback function for sleep of at least one plug-in device is sequentially called to shut down the plug-in device in the running state to hibernate the peripheral device. Because before entering the step of hibernating peripherals in the system hibernation process, the hibernation processing process of some peripherals has been completed while the system is running.
  • the power management module does not need to traverse the dormant plug-in devices and call the callback function of the plug-in device for sleep, but only needs to call the plug-in device in the running state. Calling the corresponding sleep callback function can greatly reduce the number of calls to the sleep callback function of the peripheral. There is no need to perform sleep operations on the dormant peripherals, thereby improving the speed of the dormant peripherals.
  • the power management module logs off the slave core CPU through the core processing module.
  • the slave core CPU when the system is sleeping, the slave core CPU can be offline. During the process of offline the slave core CPU, timers and tasks are not migrated, and the stop machine mechanism is used to ensure the highest priority to avoid the slave core CPU being offline. Finally, there is the problem of instability in system task execution.
  • the kernel processing module sleeps the core device, and then offline the main core CPU.
  • the execution phase of the system enters the kernel state, and peripheral interrupts will not be triggered.
  • the kernel processing module notifies ATF (Arm Trusted Firmware, Arm Secure Boot Platform) to hibernate the system.
  • ATF Arm Trusted Firmware, Arm Secure Boot Platform
  • the core processing module can notify the ATF system to enter the sleep state through the psci (power state coordination interface, power management interface specification) interface.
  • psci power state coordination interface, power management interface specification
  • Figure 3b is a schematic diagram illustrating an exemplary system wake-up process.
  • Figure 3b takes the CDC of a motor vehicle as an application scenario.
  • the CDC is divided into an instrument domain and an entertainment domain.
  • the instrument domain is a microkernel architecture (such as the microkernel architecture shown in Figure 2a).
  • the system of this application can run on embedded platforms.
  • the system wake-up process may include the following steps:
  • the power management module receives the system wake-up request and processes it.
  • the power management module can refer to the implementation process shown in Figure 4a to implement S601 through a precise CPU frequency increase mechanism.
  • the power management module's implementation process of the precise CPU frequency increase mechanism may include:
  • the power management module receives a system wake-up request.
  • the power management module determines whether the system wake-up request is a preset request.
  • the power management module may receive a system wakeup request triggered by the user to wake up the operating system of the motor vehicle.
  • the system wake-up request here is a preset wake-up request that is strongly related to user experience.
  • the system periodically sends heartbeat instructions to wake up the system to perform related operations.
  • the heartbeat instructions here do not belong to the preset wake-up requests that are strongly related to the user experience, because the user does not Don't care about the speed of this wake-up process. Moreover, this awakening process is imperceptible to the user.
  • the system wake-up request may be in the form of an event.
  • the power management module may configure a second preset event representing the preset wake-up request.
  • the system may switch to
  • S103 when the triggered system wake-up event is not the second preset event, S104 may be executed.
  • the power management module when the power management module detects that the system wake-up request is a preset request, it may determine that the target frequency to be increased for the CPU is the highest operating frequency.
  • the preset request may include a preset wake-up request.
  • the power management module can determine the CPU to be boosted and the target frequency to which the CPU is to be boosted. , here is the maximum operating frequency of the CPU.
  • the power management module can be configured with the highest operating frequency of each single-core CPU or each group of CPUs (including multi-core CPUs).
  • the power management module when the power management module detects that the system wake-up request is not a preset request, it may determine that the target frequency to be increased for the CPU is an operating frequency with the best energy efficiency ratio.
  • the system periodically sends heartbeat instructions to wake up the system to perform related operations.
  • the power management module can receive the system wake-up request sent by the interrupt subsystem shown in Figure 2c ( Heartbeat command here) to wake up the motor vehicle system.
  • the power management module detects that the system wake-up request here does not belong to the preset wake-up request that is strongly related to the user experience, and can determine the CPU to be boosted and the target frequency to which the CPU is to be boosted to which is the optimal energy efficiency ratio of the CPU. working frequency.
  • the optimal energy efficiency ratio operating frequency of each CPU is strongly related to the hardware of the CPU.
  • the operating frequency with the best energy efficiency ratio of each CPU can be determined based on the power consumption test data of the CPU of the specific chip platform at each operating frequency.
  • the power management module after S601, in S602, the power management module notifies the kernel processing module to wake up the system.
  • the kernel processing module may notify the ATF to wake up the system.
  • the kernel processing module can notify the ATF system to enter the running state through the psci interface.
  • the kernel processing module comes online to the main core CPU, and then wakes up the core device.
  • the implementation principle of S604 is similar to the implementation principle of step 22 and step 23 in the above-mentioned embodiment 2, and will not be described again here.
  • the implementation principle of S605 is similar to the implementation principle of step 24 in the above-mentioned Embodiment 2, and will not be described again here.
  • the power management module increases the frequency of the slave core CPU through the core processing module.
  • the implementation principle of S606 is similar to the implementation principle of step 25 in the above-mentioned Embodiment 2, and will not be described again here.
  • the power management module wakes up the external device through the device driver module.
  • FIG. 6a illustrates an implementation process of the runtime sleep wake-up mechanism implemented by the power management module.
  • the power management module can combine the runtime sleep wake-up mechanism implemented in Figure 6a to implement S607 through the process of waking up the external device shown in Figure 6c.
  • the power management module when the power management module receives the system wake-up request and executes the stage of waking up the peripheral device in the system wake-up process, as shown in Figure 6c, when starting to wake up the external device, the power management module can traverse the dormant device. linked list, and based on the dependency order between external devices in the dormant linked list (i.e., the above-mentioned sequential dependency relationship), the callback functions of the external devices for wake-up are called in sequence to start up the external devices that are in a closed state to wake up the external devices. set up. Because before entering the step of waking up peripherals in the system wake-up process, the wake-up processing of some peripherals has been completed while the system is running.
  • the power management module does not need to traverse the awakened plug-in devices and call the callback function of the plug-in device for waking up, but only needs to call the wake-up plug-in device.
  • plug-in devices such as plug-in devices that are turned off
  • calling the corresponding callback function for waking up can greatly reduce the number of calls to the callback function for waking up the peripheral device, and there is no need to traverse the awakened peripheral device again. Perform a wake-up operation to increase the speed of waking up peripherals.
  • the peripheral is in the awakened state, and then the device identification of the peripheral can be written into the awakened linked list, or the The peripheral's device identification is transferred from the sleep list to the wake-up list. This ensures the integrity of the data recorded in the dormant linked list or the awakened linked list.
  • the implementation process of the runtime sleep wake-up mechanism by the power management module may be partially different from the solution in Figure 6a.
  • the power management module can initialize and generate a linked list 3 after the power is turned on.
  • a linked list 3 for specific implementation details of the implementation using linked list 3 as an example, please refer to the corresponding description in the system sleep process, which will not be described again here.
  • the power management module can traverse the above example Linked list 3 to determine at least one plug-in device in the dormant state. And based on the respective sequential dependencies of at least one plug-in device, the callback function for waking up of at least one plug-in device is sequentially called to start the plug-in device in the closed state to wake up the peripheral device. Because before entering the step of waking up peripherals in the system wake-up process, the wake-up processing of some peripherals has been completed while the system is running.
  • the power management module does not need to traverse the awakened plug-in devices and call the callback function of the plug-in device for waking up, but only needs to call the plug-in device that is not in the running state.
  • calling the corresponding callback function for waking up can greatly reduce the number of calls to the callback function for waking up the peripheral, eliminating the need to perform sleep operations on the peripheral that has been awakened, thus increasing the speed of waking up the peripheral.
  • the power management module unfreezes the common tasks through the kernel processing module.
  • the power management module can send a thawing signal to a frozen common task. Then, after receiving the thawing signal, the common task can send a thawing instruction to the kernel processing module to unfreeze the common task so that the frozen common task can continue. Run to be in running state.
  • the power management module cancels the frequency increase of the slave core CPU through the kernel processing module.
  • step S609 are similar to step 28 in Embodiment 2, and will not be described again here.
  • data structure used to store data in the embodiments of this application is not limited to the linked lists exemplified in the above embodiments, and may also include but is not limited to: arrays, vectors, XML files, variables, key-value pairs, and queues. , stack, tree, heap, hash table, etc.
  • "going online” for an object can be used to mean powering on the object.
  • bringing a CPU online means powering on the CPU.
  • "Offline" an object can be used to indicate powering off the object.
  • powering off a CPU means powering off the CPU.
  • Hibernating a device can be used to mean turning off the device or powering down the device so that the device ceases to function.
  • Waking up a device can be used to signal that the device is started or that power is applied to the device so that the device operates.
  • the present application provides a system hibernation device.
  • the system sleep device includes: a filtering module, used to filter the first task in a blocked state in response to receiving a system sleep request; a freezing module, used to freeze the filtered second task that is not in a blocked state; a hibernation device A module configured to hibernate a first device of a first type based on device status information; wherein the device status information includes: a device status of at least one device of the first type, and the device status is used to indicate whether the device Information in a running state; the first device is different from a second device, wherein the second device is a device among the at least one device that is not in a running state.
  • the system sleep device further includes: a first frequency increasing module, configured to increase the operating frequency of the CPU to the first frequency when detecting that the system sleep request is a preset sleep request. ; Wherein, the first frequency is the highest operating frequency of the CPU.
  • the system sleep device further includes: a second frequency increasing module, configured to increase the operating frequency of the CPU to A second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency, the energy efficiency ratio of the CPU is the highest.
  • a second frequency increasing module configured to increase the operating frequency of the CPU to A second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency, the energy efficiency ratio of the CPU is the highest.
  • the filtering module is specifically configured to filter the first task in a blocked state among the second type of tasks; wherein the second type of task is a task other than system tasks in the operating system. other tasks.
  • system hibernation device further includes: a signal sending module, configured to send a freezing signal to the second type of task, where the freezing signal is used to instruct the task to freeze.
  • the system hibernation device further includes: a saving module, configured to save the third task that is not in the frozen state among the second tasks to the first data structure; and a traversal module, configured to Loop through the third task in the first data structure, and detect the task status of the traversed third task; delete module, used to detect the task status of the third task in the first data structure When it is in the frozen state, delete the third task in the frozen state from the first data structure; the traversal module is also used to detect that the task status of the third task is not in the first data structure. When in the frozen state, continue to loop through the first data structure until the first data structure is empty.
  • the CPU of the system is a multi-core CPU
  • the multi-core CPU includes a main core CPU and at least one slave core CPU.
  • the system hibernation device further includes: a reservation module, configured to Before the slave core CPU is powered off, the timers and tasks on the first slave core CPU are retained without migrating to the second CPU; wherein the second CPU is the second slave core CPU or the master core CPU ;
  • the at least one slave core CPU includes the first slave core CPU, or further includes the second slave core CPU.
  • the dormant device module is specifically configured to: based on the device status information, filter the second device among the first type of devices to determine the first type of the second device. A device; putting the first device to sleep.
  • the system hibernation device further includes: a device status management module, configured to: during the operation of the system, when it is detected that the third device of the first type is in a running state, The device status of the third device is recorded or updated to a first status to generate or update the device status information; wherein the first status is information indicating that the third device is in a running status; in During the operation of the system, when it is detected that the fourth device of the first type is not in a running state, the device status of the fourth device is recorded or updated to a second status to generate or update the device status. information; wherein the second state is information indicating that the fourth device is not in a running state; the device state is the first state or the second state; wherein the at least one device includes : the third device and/or the fourth device.
  • a device status management module configured to: during the operation of the system, when it is detected that the third device of the first type is in a running state, The device status of the third device is recorded or updated to a first status to generate
  • the device status management module is further configured to record or update the device status of the first device to the second status in the device status information.
  • this application provides a system wake-up device.
  • the system wake-up device includes: a wake-up device module, configured to wake up a first device of the first type based on device status information in response to receiving a system wake-up request; wherein the device status information includes: at least The device status of a device, the device status is information indicating whether the device is in a running state; the first device is different from the second device, wherein the second device is in the running state of the at least one device The device; the unfreezing module is used to unfreeze the first task in the frozen state; wherein the first task is not in the blocked state when frozen.
  • the system wake-up device further includes: a first frequency increasing module, configured to increase the operating frequency of the CPU after the CPU comes online and detects that the system wake-up request is a preset wake-up request. Increase to the first frequency; wherein the first frequency is the highest operating frequency of the CPU.
  • a first frequency increasing module configured to increase the operating frequency of the CPU after the CPU comes online and detects that the system wake-up request is a preset wake-up request. Increase to the first frequency; wherein the first frequency is the highest operating frequency of the CPU.
  • the system wake-up device further includes: a second frequency increasing module, configured to increase the frequency of the CPU when it is detected that the system wake-up request is not a preset wake-up request after the CPU comes online.
  • the operating frequency is increased to a second frequency; wherein the second frequency is smaller than the first frequency, and when the operating frequency of the CPU is the second frequency, the energy efficiency ratio of the CPU is the highest.
  • the system wake-up device further includes: a frequency increase releasing module, configured to restore the frequency modulation strategy of the CPU to the original frequency modulation strategy; wherein the original frequency modulation strategy is when receiving the The frequency modulation strategy of the CPU before the system wake-up request.
  • the first task is a task that is not in a blocked state among the second type of tasks, wherein the second type of task is a task in the operating system other than system tasks. .
  • the wake-up device module is specifically configured to: based on the device status information, filter the second device among the first type of devices to determine the first type of the second device. A device; waking up the first device.
  • the system wake-up device further includes: a device status management module, configured to: when the third device of the first type is detected to be in a running state during the operation of the system, The device status of the third device is recorded or updated to a first status to generate or update the device status information; wherein the first status is information indicating that the third device is in a running status; in During the operation of the system, when it is detected that the fourth device of the first type is not in a running state, the device status of the fourth device is recorded or updated to a second status to generate or update the device status. information; wherein the second state is information indicating that the fourth device is not in a running state; the device state is the first state or the second state; wherein the at least one device includes : the third device and/or the fourth device.
  • a device status management module configured to: when the third device of the first type is detected to be in a running state during the operation of the system, The device status of the third device is recorded or updated to a first status to generate or update the device status
  • the device status management module is further configured to record or update the device status of the first device to the first status in the device status information.
  • FIG. 7a is a schematic structural diagram of a system hibernation device provided by an embodiment of the present application.
  • the system hibernation device 500 may include: a processor 501, a transceiver 505, and optionally a memory 502.
  • the transceiver 505 may be called a transceiver unit, a transceiver, a transceiver circuit, etc., and is used to implement transceiver functions.
  • the transceiver 505 may include a receiver and a transmitter.
  • the receiver may be called a receiver or a receiving circuit, etc., used to implement the receiving function;
  • the transmitter may be called a transmitter, a transmitting circuit, etc., used to implement the transmitting function.
  • Computer program or software code or instructions 504 may be stored in the memory 502, which may also be referred to as firmware.
  • the processor 501 can control the MAC layer and the PHY layer by running the computer program or software code or instructions 503 therein, or by calling the computer program or software code or instructions 504 stored in the memory 502 to implement various embodiments of the present application.
  • the processor 501 may be a central processing unit (CPU), and the memory 502 may be a read-only memory (ROM) or a random access memory (RAM).
  • the processor 501 and transceiver 505 described in this application can be implemented in integrated circuits (ICs), analog ICs, radio frequency integrated circuits RFICs, mixed signal ICs, application specific integrated circuits (ASICs), printed circuits on printed circuit board (PCB), electronic equipment, etc.
  • ICs integrated circuits
  • analog ICs analog ICs
  • radio frequency integrated circuits RFICs radio frequency integrated circuits
  • mixed signal ICs mixed signal ICs
  • ASICs application specific integrated circuits
  • PCB printed circuits on printed circuit board
  • electronic equipment etc.
  • the above-mentioned system sleep device 500 may also include an antenna 506.
  • Each module included in the system sleep device 500 is only an example, and this application does not limit this.
  • FIG. 7b is a schematic structural diagram of a system wake-up device provided by an embodiment of the present application.
  • the system wake-up device 500 may include: a processor 501, a transceiver 505, and optionally a memory 502.
  • the transceiver 505 may be called a transceiver unit, a transceiver, a transceiver circuit, etc., and is used to implement transceiver functions.
  • the transceiver 505 may include a receiver and a transmitter.
  • the receiver may be called a receiver or a receiving circuit, etc., used to implement the receiving function;
  • the transmitter may be called a transmitter, a transmitting circuit, etc., used to implement the transmitting function.
  • Computer program or software code or instructions 504 may be stored in the memory 502, which may also be referred to as firmware.
  • the processor 501 can control the MAC layer and the PHY layer by running the computer program or software code or instructions 503 therein, or by calling the computer program or software code or instructions 504 stored in the memory 502 to implement various embodiments of the present application. Provided system wake-up method.
  • the processor 501 may be a central processing unit (CPU), and the memory 502 may be a read-only memory (ROM) or a random access memory (RAM).
  • the processor 501 and transceiver 505 described in this application can be implemented in integrated circuits (ICs), analog ICs, radio frequency integrated circuits RFICs, mixed signal ICs, application specific integrated circuits (ASICs), printed circuits on printed circuit board (PCB), electronic equipment, etc.
  • ICs integrated circuits
  • analog ICs analog ICs
  • radio frequency integrated circuits RFICs radio frequency integrated circuits
  • mixed signal ICs mixed signal ICs
  • ASICs application specific integrated circuits
  • PCB printed circuits on printed circuit board
  • electronic equipment etc.
  • the above-mentioned system wake-up device 500 may also include an antenna 506.
  • Each module included in the system wake-up device 500 is only an example, and this application does not limit this.
  • the structure of the system hibernation device may not be limited by Figure 7a.
  • the structure of the system wake-up device may not be limited by Figure 7b.
  • the system hibernation device and the system wake-up device may be independent devices or may be part of a larger device.
  • the implementation form of the system hibernation device or the system wake-up device may be:
  • An independent integrated circuit IC, or chip, or chip system or subsystem (2) A collection of one or more ICs.
  • the IC collection may also include storage for storing data and instructions. Components; (3) Modules that can be embedded in other equipment; (4) Vehicle-mounted equipment, etc.; (5) Others, etc.
  • the system hibernation device or the system wake-up device is implemented as a chip or a chip system
  • the chip shown in Figure 8 includes a processor 601 and an interface 602.
  • the number of processors 601 may be one or more, and the number of interfaces 602 may be multiple.
  • the chip or chip system may include memory 603 .
  • embodiments of the present application also provide a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program.
  • the computer program includes at least one section of code.
  • the at least one section of code can be executed by a computer to control the computer. It is used to implement the above system sleep method or system wake-up method embodiments.
  • embodiments of the present application also provide a computer program, which when the computer program is executed by a terminal device, is used to implement the above system sleep method or system wake-up method embodiments.
  • the program may be stored in whole or in part on a storage medium packaged with the processor, or in part or in whole on a memory that is not packaged with the processor.
  • embodiments of the present application also provide a chip including a network port controller and a processor.
  • the network port controller and processor can implement the above system sleep method or system wake-up method embodiments.
  • the steps of the methods or algorithms described in connection with the disclosure of the embodiments of this application can be implemented in hardware or by a processor executing software instructions.
  • Software instructions can be composed of corresponding software modules.
  • Software modules can be stored in random access memory (Random Access Memory, RAM), flash memory, read only memory (Read Only Memory, ROM), erasable programmable read only memory ( Erasable Programmable ROM (EPROM), electrically erasable programmable read-only memory (Electrically EPROM, EEPROM), register, hard disk, removable hard disk, compact disc (CD-ROM) or any other form of storage media well known in the art.
  • An exemplary storage medium is coupled to the processor such that the processor can read information from the storage medium and write information to the storage medium.
  • the storage medium can also be an integral part of the processor.
  • the processor and storage media may be located in an ASIC.
  • Computer-readable media includes computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • Storage media can be any available media that can be accessed by a general purpose or special purpose computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
  • Power Sources (AREA)

Abstract

本申请实施例提供了一种***休眠方法及装置、***唤醒方法及装置，涉及操作***技术领域，该方法无需对处于阻塞状态的任务进行冻结，可减少冻结或解冻的任务数量，以及可在***运行时维护设备状态信息，从而可在***休眠或唤醒时，减少休眠或唤醒的设备数量，从而提升***休眠、唤醒的速度，降低***休眠唤醒的响应时长，提升用户体验，并提升待机时长。

Description

***休眠方法及装置、***唤醒方法及装置
本申请要求于2022年04月29日提交中国国家知识产权局、申请号为202210466672.6、申请名称为“***休眠方法及装置、***唤醒方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及操作***技术领域，尤其涉及一种***休眠方法及装置、***唤醒方法及装置。
背景技术
在本领域，电子设备可依据电源的不同状态，在操作***不需要工作时，控制操作***进入休眠状态，以节约***功耗。当有唤醒类型的中断发生时，电子设备可以将设备的操作***从休眠状态唤醒恢复运行状态(也称唤醒状态)，以使***恢复工作。
目前，***休眠和唤醒过程耗时较长，***休眠和唤醒的速度较慢。从而导致电子设备的休眠唤醒(例如亮灭屏)的响应时间较长，影响用户体验，且造成***的待机时长缩短。
发明内容
为了解决上述技术问题，本申请提供一种***休眠方法及装置、***唤醒方法及装置。在该方法中可减少冻结或解冻的任务数量，休眠或唤醒的设备数量，从而提升***休眠、唤醒的速度，降低***休眠唤醒的响应时长，提升用户体验，并提升待机时长。
在一种可能的实施方式中，本申请提供一种***休眠方法。该方法包括：响应于接收到***休眠请求，过滤处于阻塞状态的第一任务；对过滤后的未处于阻塞状态的第二任务进行冻结；基于设备状态信息，对第一类型的第一设备进行休眠；其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中未处于运行状态的设备。
示例性的，第二任务为将第一任务过滤后的任务，第二任务未处于阻塞状态(也可描述为处于非阻塞状态)。
示例性的，第二任务可为对操作***中的全部(或部分)任务，过滤掉处于阻塞状态的第一任务后，剩余的任务。示例性的，可通过遍历任务来实现对待冻结的任务的筛选。
示例性的，本实施方式，即便在休眠第一设备之前，过滤掉的处于阻塞状态的任务的任务状态切换为运行状态，本实施方式由于可对未处于阻塞状态的第二任务进行冻结，那么阻塞状态的任务唤醒后仍旧可被冻结，以确保***休眠的可靠性。
示例性的，第一类型的设备，用于表示不影响CPU运行的设备。第一类型的设备可 为外挂设备(简称外设)。
示例性的，对于第一类型的设备可配置有预设设备列表。
示例性的，对设备休眠可使该设备停止运行，或关闭、或下电。
示例性的，设备状态信息可为在所述***运行过程中，基于所述至少一个设备是否处于运行状态而生成。本申请可在***运行时，检测至少一个外挂设备是否处于运行状态，从而可在***运行时维护外挂设备的设备状态。
示例性的，设备状态可包括第一状态或第二状态，其中，第一状态用于表示设备处于运行状态(例如启动状态，上电状态等)，示例性的，设备处于运行状态也称设备处于唤醒状态；第二状态用于表示设备未处于运行状态(例如关闭状态、停止运行状态、下电状态等)，示例性的，设备未处于运行状态也称设备处于休眠状态。
示例性的，在冻结任务之后，在休眠外设之前，***维护生成的设备状态信息中可包括全部外设的设备状态信息，或者，包括部分外设的设备状态信息。
那么本实施例中，在休眠外设时，无需对设备状态信息中记录的未处于运行状态(也称已休眠)的第二设备进行休眠，只需对***的外设中，除第二设备之外的外设(上文提及的第一设备)进行休眠，以使除第二设备之外的外设可被停止运行，从而达到休眠外设的效果。该***休眠过程减少了休眠外设的数量，提升了外设休眠速度。
示例性的，考虑到上述设备状态信息是在***运行过程中，基于检测到的外设是否处于运行状态，而动态生成地数据。因此，设备状态信息可以仅包括部分外设的设备状态信息，那么本实施例中，***休眠的外设(即第一设备)可以是记录的设备状态信息中的外设，也可以是还未记录在设备状态信息中的外设，本申请对此不做限制。
示例性的，设备状态信息的数据结构可以是链表。该链表可以是一个链表，用于记录所有外设，以及可标记检测到的外设的设备状态。该链表也可以是两个链表，一个链表用于记录处于运行状态的外设，另一个链表用于记录未处于运行状态的外设。本申请对此不做限制。
本申请实施例中，在***休眠时，可冻结任务，然后，休眠设备。在冻结任务时，可不对处于阻塞状态的任务进行冻结，从而减少了冻结任务的数量，加快了任务冻结速度。以及在休眠设备时，可基于***运行时所维护的设备状态信息，来减少设备休眠数量，从而加快设备休眠过程。这样，可整体提升***休眠速度，缩短***休眠过程的时长。从而可使安装有该***的电子设备，***休眠(例如灭屏)的响应时间缩短，提升用户体验。且***休眠过程加速后，可使***更快的进入到休眠状态，从而降低***功耗，提升***的待机时长。
在一种可能的实施方式中，所述过滤处于阻塞状态的第一任务之前，所述方法还包括：在检测到所述***休眠请求为预设休眠请求时，将CPU的工作频率提高至第一频率；其中，所述第一频率为所述CPU的最高工作频率。
示例性的，该***的CPU为多核CPU时，这里提高频率的CPU可以是主核CPU，和/或从核CPU。
示例性的，预设休眠请求为与用户体验相关的休眠请求。
本实施例中，在***休眠请求为预设休眠请求时，可将CPU的工作频率提高至最高工作频率，以加速CPU的指令执行速度，那么在响应于该***休眠请求而执行上述***休眠的相关操作时，可对***休眠过程进行整体加速(例如任务冻结过程、休眠设备过程等均可以被加速)，以最大程度的提升用户体验。
在一种可能的实施方式中，所述过滤处于阻塞状态的第一任务之前，所述方法还包括：在检测到所述***休眠请求不为预设休眠请求时，将所述CPU的工作频率提高至第二频率；其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
示例性的，可将第二频率命名为CPU的最佳能效比的工作频率。
示例性的，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高，可以理解为：在CPU处于不同工作频率下，CPU在完成相同量的指令执行任务时，其中，该CPU的工作频率为该第二频率时，该CPU的功耗最低。
示例性的，该***的CPU为多核CPU时，这里提高频率的CPU可以是主核CPU，和/或从核CPU。
示例性的，最佳能效比的工作频率a，可用于表示在所述CPU的工作频率为工作频率a时，所述CPU的能效比最高，所述CPU的功耗最低。
本实施例中，在***休眠请求不为预设休眠请求时，则说明该***休眠请求与用户体验不相关，那么用户并不关心***休眠过程的速度快慢，那么可为了降低CPU功耗，可将CPU的工作频率调节至上述最佳能效比的工作频率，以使最大程度的节省***功耗。
可以理解的是，本申请提供了在***休眠或唤醒场景下，使用的对CPU的调频策略，该调频策略包括在***休眠请求或***唤醒请求为预设请求时，将CPU提频至最高工作频率，在***休眠请求或***唤醒请求不为预设请求时，将CPU提频至最佳能效比的工作频率。
在一种可能的实施方式中，所述过滤处于阻塞状态的第一任务，包括：在第二类型的任务中，过滤处于阻塞状态的第一任务；其中，所述第二类型的任务为操作***中除***任务之外的任务。
示例性的，在微内核架构下，***中的任务可包括用户态任务和内核态任务。
其中，用户态任务可包括普通任务和***服务任务(也是一种***任务)。内核态任务均为***任务。
本实施例在冻结任务时，无需对***任务(包括用户态中的***服务任务以及内核态中的***任务)进行冻结，只需对普通任务中未处于阻塞状态的任务进行冻结。***任务数量较多，无需冻结***任务，可大幅提升任务冻结速度，从而缩短***休眠时长。
在一种可能的实施方式中，所述接收到***休眠请求之后，所述方法还包括：对所述第二类型的任务发送冻结信号，所述冻结信号用于指示任务进行冻结。
示例性的，在接收到***休眠请求后，本申请实施例可对所有普通任务发送冻结信号，这里的普通任务包括处于阻塞状态的普通任务。那么虽然处于阻塞状态的任务无需冻结，但是，仍旧可向阻塞状态的任务发送冻结信号，那么即便处于阻塞状态的任务，在休眠外设之前处于非阻塞状态，该任务仍旧可以对冻结信号进行处理，以冻结该不再处于阻塞状态的任务，确保阻塞状态的任务恢复运行后仍旧可被冻结，提升***休眠的可靠性。
在一种可能的实施方式中，所述过滤处于阻塞状态的第一任务之后，所述基于设备状态信息，对第一类型的第一设备进行休眠之前，所述方法还包括：将所述第二任务中未处于冻结状态的第三任务，保存至第一数据结构；对第一数据结构中的所述第三任务进行循环遍历，并对遍历的所述第三任务检测任务状态；在所述第一数据结构中检测到第三任务的任务状态为所述冻结状态时，将处于冻结状态的该第三任务从所述第一数据结构删除；在所述第一数据结构中检测到第三任务的任务状态不为所述冻结状态时，继续循环遍历所述第一数据结构，直至所述第一数据结构为空。
示例性的，第二任务包括第三任务。
示例性的，在向第二类型的任务发送冻结信号后，第二类型的任务中未处于阻塞状态的任务(即第二任务)可对冻结信号进行处理以冻结任务。为了确定每个第二任务是否均以冻结而处于冻结状态，则本申请可对第二任务的任务状态进行检测，以将还未冻结的(处于未冻结状态)第三任务保存至第一数据结构。
然后，可对第一数据结构中的任务进行循环遍历检测任务状态，以将处于冻结状态的任务从第一数据结构中删除，那么随着处于非阻塞状态的任务(例如第二任务)的冻结进度的推进，该第一数据结构中的任务越来越少。第一数据结构仅保存未冻结的任务，从而可避免大量已冻结任务的任务状态的冗余检查，提高了对未冻结任务的遍历效率，进而加速任务冻结过程。在第一数据结构为空时，那么第一数据结构不再包括任何任务，说明处于非阻塞状态的任务均已冻结，任务冻结过程结束。
示例性的，可在预设时长内对第一数据结构中的第三任务进行循环遍历，从而避免第一数据结构中的第三任务长时间未冻结，而影响***休眠速度。
在一种可能的实施方式中，所述***的CPU为多核CPU，所述多核CPU包括主核CPU和至少一个从核CPU，所述基于设备状态信息，对第一类型的第一设备进行休眠之后，所述方法还包括：在对第一从核CPU下电之前，将所述第一从核CPU上的定时器及任务进行保留而不迁移至第二CPU；其中，所述第二CPU为第二从核CPU或所述主核CPU；所述至少一个从核CPU包括所述第一从核CPU，或者，进一步包括所述第二从核CPU。
这样，在过滤掉的处于阻塞状态的任务中，运行在从核CPU上的任务，不会迁移到运行的其他CPU上。那么在从核CPU下线之后，该从核CPU上的处于阻塞状态的任务，即便从阻塞状态更新为非阻塞状态，该任务也不会被执行，从而确保在休眠非核心设备(也称外设)之前，阻塞状态的任务的任务状态，即便更新为非阻塞状态，该任务也会按照接收到的冻结信号进行冻结状态，而无法运行。
示例性的，例如从核CPU上的定时器的任务为阻塞状态，而被添加到阻塞任务链表，在该定时器定时结束后，该定时器对应的任务可发送中断至该从核CPU。但是，由于从核CPU已下线，该定时器对应的任务也没有迁移到其他运行的CPU上，使得***进入内核后，不会再接收到已下线的从核CPU的任务发起的中断，从而不会执行阻塞后唤醒的任务，保证阻塞任务不冻结正确性。
在一种可能的实施方式中，所述基于设备状态信息，对第一类型的第一设备进行休眠，包括：基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；对所述第一设备进行休眠。
在本申请实施例中，可在***的外设(例如全部外设)中，过滤掉已休眠(例如处于关闭状态)的外设，并对过滤后剩余的外设进行休眠，从而减少休眠的设备的数量。
在一种可能的实施方式中，所述方法还包括：在所述***运行过程中，检测到所述第一类型的第三设备处于运行状态时，将所述第三设备的设备状态，记录或更新为第一状态，以生成或更新所述设备状态信息；其中，所述第一状态为用于表示所述第三设备处于运行状态的信息；在所述***运行过程中，检测到所述第一类型的第四设备未处于运行状态时，将所述第四设备的设备状态，记录或更新为第二状态，以生成或更新所述设备状态信息；其中，所述第二状态为用于表示所述第四设备未处于运行状态的信息；所述设备状态为所述第一状态或所述第二状态；其中，所述至少一个设备包括：所述第三设备和/或所述第四设备。
示例性的，在***运行过程中，说明该操作***未进入到S3状态(休眠状态)。
其中，S3状态表示仅维持内存等必要的设备供电，以确保数据不丢失，其它部件处于关闭状态，***的耗电量极低。
示例性的，在***运行时，检测到的外设1处于运行状态。那么在设备状态信息对应的数据结构(例如链表)中，未记录有外设1的设备状态时，则本申请可在该数据结构中记录外设1的设备状态为运行状态，从而生成设备状态信息。
示例性的，在***运行时，检测到的外设2处于运行状态。那么在设备状态信息对应的数据结构(例如链表)中，记录有外设2的设备状态(例如停止运行状态)时，则本申请可在该数据结构中，将外设2的设备状态从停止运行状态更新为运行状态，从而更新设备状态信息。
以上两个例子，用于读者理解记录或更新设备状态，以生成或更新设备状态信息的意义。
在本申请实施例中，通过在***运行时，对检测到的处于运行状态的设备，和/或，检测到的未处于运行状态的设备，记录或更新至上述数据结构(例如链表)中，从而可生成或更新设备状态信息。便于在***休眠时，基于该设备状态信息中记录的处于第二状态(未运行状态)的设备，来减少休眠的设备的数量，提升设备休眠速度。
在一种可能的实施方式中，所述基于设备状态信息，对第一类型的第一设备进行休 眠之后，所述方法还包括：在所述设备状态信息中，记录或更新所述第一设备的设备状态为所述第二状态。
示例性的，在***休眠过程中，基于设备状态信息，对第一设备(例如部分外设)进行休眠后，可使全部外设休眠，那么为了确保设备状态信息的准确性，可将在***休眠过程中休眠的外设的状态信息，记录或更新至设备状态信息中，以使第一设备在设备状态信息中的设备状态为未运行状态(例如第二状态)。
在一种可能的实施方式中，本申请提供一种***唤醒方法。该方法包括：响应于接收到***唤醒请求，基于设备状态信息，对第一类型的第一设备进行唤醒；其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中处于运行状态的设备；对处于冻结状态的第一任务进行解冻；其中，所述第一任务在冻结时未处于阻塞状态。
本申请实施例中与***休眠方法相似之处，以及相同的名词和对象，可参照上述***休眠方法实施例的相关描述，这里不再赘述。
示例性的，设备状态信息可为在所述***运行过程中，基于所述至少一个设备是否处于运行状态而生成。本申请可在***运行时，检测至少一个外挂设备是否处于运行状态，从而可在***运行时维护外挂设备的设备状态。
示例性的，设备状态可包括第一状态或第二状态，其中，第一状态用于表示设备处于运行状态(例如启动状态，上电状态等)，示例性的，设备处于运行状态也称设备处于唤醒状态；第二状态用于表示设备未处于运行状态(例如关闭状态、停止运行状态、下电状态等)，示例性的，设备未处于运行状态也称设备处于休眠状态。设备处于运行状态也称设备处于唤醒状态。
本申请实施例中，在***唤醒时，可唤醒设备，然后解冻任务。在唤醒设备时，可基于***运行时所维护的设备状态信息，来减少设备唤醒数量，从而加快设备唤醒过程。在解冻任务时，可不对处于阻塞状态的任务进行解冻，从而减少了解冻任务的数量，加快了任务解冻速度。这样，可整体提升***唤醒速度，缩短***唤醒过程的时长。从而可使安装有该***的电子设备，***唤醒(例如亮屏)的响应时间缩短，提升用户体验。
在一种可能的实施方式中，所述基于设备状态信息，对第一类型的第一设备进行唤醒之前，所述方法还包括：在CPU上线之后，在检测到所述***唤醒请求为预设唤醒请求时，将所述CPU的工作频率提高至第一频率；其中，所述第一频率为所述CPU的最高工作频率。
示例性的，***中的该CPU为单核CPU时，可在主核CPU上线之后，按照本申请的提频策略，对该主核CPU提频。示例性的，该***中的该CPU为多核CPU时，则可在从核CPU上线之后，按照本申请的提频策略，对该从核CPU进行提频。
示例性的，预设唤醒请求为与用户体验相关的唤醒请求。
本实施方式的效果及原理，与上述***休眠方法的相对应的提频的实施方式的效果 和原理类似，这里不再赘述。
本实施例中，在***唤醒请求为预设唤醒请求时，可将CPU的工作频率提高至最高工作频率，以加速CPU的指令执行速度，那么在响应于该***唤醒请求而执行上述***唤醒的相关操作时，可对***唤醒过程进行整体加速(例如任务解冻过程、设备唤醒过程等均可以被加速)，以最大程度的提升用户体验。
在一种可能的实施方式中，所述基于设备状态信息，对第一类型的第一设备进行唤醒之前，所述方法还包括：在所述CPU上线之后，在检测到所述***唤醒请求不为预设唤醒请求时，将所述CPU的工作频率提高至第二频率；其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
本实施方式的效果及原理，与上述***休眠方法的相对应的提频的实施方式的效果和原理类似，这里不再赘述。
本实施例中，在***唤醒请求不为预设唤醒请求时，则说明该***唤醒请求与用户体验不相关，那么用户并不关心***唤醒过程的速度快慢，那么可为了降低功耗，可将CPU的工作频率调节至上述最佳能效比的工作频率，以使最大程度的节省***功耗。
可以理解的是，本申请提供了在***休眠或唤醒场景下，使用的对CPU的调频策略，该调频策略包括在***休眠请求或***唤醒请求为预设请求时，将CPU提频至最高工作频率，在***休眠请求或***唤醒请求不为预设请求时，将CPU提频至最佳能效比的工作频率。
在一种可能的实施方式中，所述对处于冻结状态的第一任务进行解冻之后，所述方法还包括：将所述CPU的调频策略，恢复为原调频策略；其中，所述原调频策略为在接收到所述***唤醒请求之前，所述CPU的调频策略。
示例性的，本申请对CPU的原调频策略不做限制，该原调频策略为在进入***休眠或唤醒流程的本申请的提频操作之前，该CPU的调频策略。
示例性的，原调频策略可为固定调频策略，即将CPU的工作频率调整至该策略配置的固定工作频率。示例性的，原调频策略也可以为动态调频策略，即根据CPU上运行的任务，来灵活调整CPU的工作频率。
在一种可能的实施方式中，所述第一任务为在第二类型的任务中，未处于阻塞状态的任务，其中，所述第二类型的任务为操作***中除***任务之外的任务。
本实施方式的效果及原理，与上述***休眠方法的相对应的，对***任务和阻塞状态的任务进行过滤的实施方式的效果和原理类似，这里不再赘述。
本实施例在解冻任务时，无需对***任务(包括用户态中的***服务任务以及内核态中的***任务)进行解冻，只需对普通任务中未处于阻塞状态的任务进行解冻。***任务数量较多，无需解冻***任务，可大幅提升任务解冻速度，从而缩短***唤醒时长。
在一种可能的实施方式中，所述基于设备状态信息，对第一类型的第一设备进行唤 醒，包括：基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；对所述第一设备进行唤醒。
在本申请实施例中，可在***的外设(例如全部外设)中，过滤掉已唤醒(例如处于运行状态)的外设，并对过滤后剩余的外设进行唤醒，从而减少唤醒的设备的数量。
在一种可能的实施方式中，所述方法还包括：在所述***运行过程中，检测到所述第一类型的第三设备处于运行状态时，将所述第三设备的设备状态，记录或更新为第一状态，以生成或更新所述设备状态信息；其中，所述第一状态为用于表示所述第三设备处于运行状态的信息；在所述***运行过程中，检测到所述第一类型的第四设备未处于运行状态时，将所述第四设备的设备状态，记录或更新为第二状态，以生成或更新所述设备状态信息；其中，所述第二状态为用于表示所述第四设备未处于运行状态的信息；所述设备状态为所述第一状态或所述第二状态；其中，所述至少一个设备包括：所述第三设备和/或所述第四设备。
本实施方式的效果及原理，与上述***休眠方法的相对应的，对生成和更新色环保状态信息的实施例方式的效果和原理类似，这里不再赘述。
在本申请实施例中，通过在***运行时，对检测到的处于运行状态的设备，和/或，检测到的未处于运行状态的设备，记录或更新至上述数据结构(例如链表)中，从而可生成或更新设备状态信息。便于在***唤醒时，基于该设备状态信息中记录的处于第一状态(运行状态)的设备，来减少唤醒的设备的数量，提升设备唤醒速度。
在一种可能的实施方式中，所述基于设备状态信息，对第一类型的第一设备进行唤醒之后，所述方法还包括：在所述设备状态信息中，记录或更新所述第一设备的设备状态为所述第一状态。
示例性的，在***唤醒程中，基于设备状态信息，对第一设备(例如部分外设)进行唤醒后，可使全部外设唤醒，那么为了确保设备状态信息的准确性，可将在***唤醒过程中唤醒的外设的状态信息，记录或更新至设备状态信息中，以使第一设备在设备状态信息中的设备状态为运行状态(例如第一状态)。
在一种可能的实施方式中，本申请提供一种***休眠装置。该***休眠装置包括：过滤模块，用于响应于接收到***休眠请求，过滤处于阻塞状态的第一任务；冻结模块，用于对过滤后的未处于阻塞状态的第二任务进行冻结；休眠设备模块，用于基于设备状态信息，对第一类型的第一设备进行休眠；其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中未处于运行状态的设备。
在一种可能的实施方式中，所述***休眠装置还包括：第一提频模块，用于在检测到所述***休眠请求为预设休眠请求时，将CPU的工作频率提高至第一频率；其中，所 述第一频率为所述CPU的最高工作频率。
在一种可能的实施方式中，所述***休眠装置还包括：第二提频模块，用于在检测到所述***休眠请求不为预设休眠请求时，将所述CPU的工作频率提高至第二频率；其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
在一种可能的实施方式中，所述过滤模块，具体用于在第二类型的任务中，过滤处于阻塞状态的第一任务；其中，所述第二类型的任务为操作***中除***任务之外的任务。
在一种可能的实施方式中，所述***休眠装置还包括：发送信号模块，用于对所述第二类型的任务发送冻结信号，所述冻结信号用于指示任务进行冻结。
在一种可能的实施方式中，所述***休眠装置还包括：保存模块，用于将所述第二任务中未处于冻结状态的第三任务，保存至第一数据结构；遍历模块，用于对第一数据结构中的所述第三任务进行循环遍历，并对遍历的所述第三任务检测任务状态；删除模块，用于在所述第一数据结构中检测到第三任务的任务状态为所述冻结状态时，将处于冻结状态的该第三任务从所述第一数据结构删除；所述遍历模块，还用于在所述第一数据结构中检测到第三任务的任务状态不为所述冻结状态时，继续循环遍历所述第一数据结构，直至所述第一数据结构为空。
在一种可能的实施方式中，所述***的CPU为多核CPU，所述多核CPU包括主核CPU和至少一个从核CPU，所述***休眠装置还包括：保留模块，用于在对第一从核CPU下电之前，将所述第一从核CPU上的定时器及任务进行保留而不迁移至第二CPU；其中，所述第二CPU为第二从核CPU或所述主核CPU；所述至少一个从核CPU包括所述第一从核CPU，或者，进一步包括所述第二从核CPU。
在一种可能的实施方式中，所述休眠设备模块，具体用于：基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；对所述第一设备进行休眠。
在一种可能的实施方式中，所述***休眠装置还包括：设备状态管理模块，用于：在所述***运行过程中，检测到所述第一类型的第三设备处于运行状态时，将所述第三设备的设备状态，记录或更新为第一状态，以生成或更新所述设备状态信息；其中，所述第一状态为用于表示所述第三设备处于运行状态的信息；在所述***运行过程中，检测到所述第一类型的第四设备未处于运行状态时，将所述第四设备的设备状态，记录或更新为第二状态，以生成或更新所述设备状态信息；其中，所述第二状态为用于表示所 述第四设备未处于运行状态的信息；所述设备状态为所述第一状态或所述第二状态；其中，所述至少一个设备包括：所述第三设备和/或所述第四设备。
在一种可能的实施方式中，所述设备状态管理模块，还用于在所述设备状态信息中，记录或更新所述第一设备的设备状态为所述第二状态。
上述各实施方式的***休眠装置的效果，与上述各实施方式的***休眠方法的效果类似，这里不再赘述。
在一种可能的实施方式中，本申请提供一种***唤醒装置。该***唤醒装置包括：唤醒设备模块，用于响应于接收到***唤醒请求，基于设备状态信息，对第一类型的第一设备进行唤醒；其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中处于运行状态的设备；解冻模块，用于对处于冻结状态的第一任务进行解冻；其中，所述第一任务在冻结时未处于阻塞状态。
在一种可能的实施方式中，所述***唤醒装置还包括：第一提频模块，用于在CPU上线之后，在检测到所述***唤醒请求为预设唤醒请求时，将CPU的工作频率提高至第一频率；其中，所述第一频率为所述CPU的最高工作频率。
在一种可能的实施方式中，所述***唤醒装置还包括：第二提频模块，用于在CPU上线之后，在检测到所述***唤醒请求不为预设唤醒请求时，将所述CPU的工作频率提高至第二频率；其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
在一种可能的实施方式中，所述***唤醒装置还包括：解除提频模块，用于将所述CPU的调频策略，恢复为原调频策略；其中，所述原调频策略为在接收到所述***唤醒请求之前，所述CPU的调频策略。
在一种可能的实施方式中，所述第一任务为在第二类型的任务中，未处于阻塞状态的任务，其中，所述第二类型的任务为操作***中除***任务之外的任务。
在一种可能的实施方式中，所述唤醒设备模块，具体用于：基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；对所述第一设备进行唤醒。
在一种可能的实施方式中，所述***唤醒装置还包括：设备状态管理模块，用于：在所述***运行过程中，检测到所述第一类型的第三设备处于运行状态时，将所述第三 设备的设备状态，记录或更新为第一状态，以生成或更新所述设备状态信息；其中，所述第一状态为用于表示所述第三设备处于运行状态的信息；在所述***运行过程中，检测到所述第一类型的第四设备未处于运行状态时，将所述第四设备的设备状态，记录或更新为第二状态，以生成或更新所述设备状态信息；其中，所述第二状态为用于表示所述第四设备未处于运行状态的信息；所述设备状态为所述第一状态或所述第二状态；其中，所述至少一个设备包括：所述第三设备和/或所述第四设备。
在一种可能的实施方式中，所述设备状态管理模块，还用于在所述设备状态信息中，记录或更新所述第一设备的设备状态为所述第一状态。
上述各实施方式的***唤醒装置的效果，与上述各实施方式的***唤醒方法的效果类似，这里不再赘述。
在一种可能的实施方式中，本申请提供一种***休眠装置。该***休眠装置包括一个或多个接口电路和一个或多个处理器；所述接口电路用于从存储器接收信号，并向所述处理器发送所述信号，所述信号包括存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，所述处理器可实现上述任意一种实施方式中的***休眠方法。
本实施方式的***休眠装置的效果，与上述各实施方式的***休眠方法的效果类似，这里不再赘述。
在一种可能的实施方式中，本申请提供一种***唤醒装置。该***唤醒装置包括一个或多个接口电路和一个或多个处理器；所述接口电路用于从存储器接收信号，并向所述处理器发送所述信号，所述信号包括存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，所述处理器可实现上述任意一种实施方式中的***唤醒方法。
本实施方式的***唤醒装置的效果，与上述各实施方式的***唤醒方法的效果类似，这里不再赘述。
在一种可能的实施方式中，本申请提供一种计算机可读存储介质。计算机可读存储介质存储有计算机程序，当计算机程序运行在计算机或处理器上时，使得计算机或处理器执行上述任意一种实施方式中的***休眠方法，或使得计算机或处理器执行上述任意一种实施方式中的***唤醒方法。
本实施方式的计算机可读存储介质的效果，与上述各实施方式的***休眠方法或***唤醒方法的效果类似，这里不再赘述。
在一种可能的实施方式中，本申请提供一种计算机程序产品。计算机程序产品包含软件程序，当软件程序被计算机或处理器执行时，使得上述任意一个实施方式中的***休眠方法或***唤醒方法被执行。
本实施方式的计算机程序产品的效果，与上述各实施方式的***休眠方法或***唤 醒方法的效果类似，这里不再赘述。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为示例性示出的传统技术中***休眠及唤醒的过程示意图；
图2a为为示例性示出的主机的微内核架构示意图；
图2b为示例性示出的***软件架构示意图；
图2c为示例性示出的各模块的交互示意图；
图3a为示例性示出的***休眠过程的示意图；
图3b为示例性示出的***唤醒过程的示意图；
图4a为示例性示出的提频过程的示意图；
图4b为示例性示出的测试数据的曲线图；
图5a为示例性示出的冻结任务过程的示意图；
图5b为示例性示出的冻结任务过程的示意图；
图6a为示例性示出的设备状态管理的过程示意图；
图6b为示例性示出的休眠设备的过程示意图；
图6c为示例性示出的唤醒设备的过程示意图；
图7a为本申请实施例提供的一种装置的结构示意图；
图7b为本申请实施例提供的一种装置的结构示意图；
图8为本申请实施例提供的一种芯片的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个***是指两个或两个以上的***。
在计算机操作***的休眠唤醒领域中，ACPI(高级配置电源管理接口，Advanced Configuration and Power Interface)定义了六种电源状态，分别为S0-S5：
S0：工作状态(也称运行状态)，所有设备全开。
S1：Power on Suspend(简称POS)，CPU时钟关闭，其它部件仍然正常工作。
S2：CPU停止运行，总线时钟关闭，其它部件仍然正常工作。
S3：Suspend to RAM(简称STR，也称休眠状态)，仅维持内存等必要的设备供电，以确保数据不丢失，其它部件处于关闭状态，***的耗电量极低。
S4：Suspend to Disk(简称STD)，***主电源关闭，但是硬盘仍然带电并可以被唤醒，是比S4更加省电的电源状态。
S5：包括电源在内的所有设备全部关闭，***的耗电量为0。
在本领域，电子设备可依据电源的不同状态，在操作***不需要工作时，控制操作***进入S3(也称休眠状态)，以节约***功耗。当有唤醒类型的中断发生时，电子设备可以将设备的操作***从休眠状态唤醒恢复到S0(也称运行状态，或唤醒状态)，以使***恢复工作。
目前的电子设备普遍存在休眠及唤醒功能。图1为示例性示出的传统技术中在Linux内核架构下的***休眠及唤醒的过程示意图。
如图1所示，休眠流程如下：首先由用户态发起休眠请求，休眠请求模块可接收到该休眠请求。然后，冻结任务模块可基于该休眠请求冻结任务，具体为冻结用户态任务和内核态任务。示例性的，冻结进程可以理解为内核将进程列表中所有进程的状态均设置为停止状态，并且保存所有进程的上下文。示例性的，冻结内核态任务可将内核态的任务(例如***任务)的状态设置为停止状态。接着，休眠外设模块，可调用注册的设备的suspend(挂起)的回调函数，按照注册顺序休眠外设。然后，下线从核模块可将从核CPU休眠，以使从核CPU下线。接着，下线核心设备模块可控制核心设备停止运行，以下线核心设备。最后，休眠主核模块可控制主核CPU进入休眠状态，以使主核CPU休眠。
唤醒流程如下：处于休眠状态的操作***被图1所示的中断或者其他事件唤醒，从图1可以看到，唤醒流程与休眠流程的步骤执行顺序是相反的。下面简单描述，首先，主核唤醒模块可将主核CPU启动，以唤醒主核。然后，上线核心设备模块可启动核心设备，以使核心设备上线。接着，上线从核模块可启动从核CPU以使从核CPU上线。然后，唤醒外设模块可启动外设，以唤醒外设。最后，解冻任务模块可启动处于停止状态的用户态任务和内核态任务，以解冻任务，使任务处于运行状态，至此唤醒过程完成。
在图1的方案中，在休眠过程中，冻结任务的过程耗时较长，且需要冻结的任务数量越多，该过程耗时就更长；此外，在休眠及唤醒的过程中，休眠设备(包括外设)和唤醒设备(包括外设)的过程耗时也较长，且电子设备中的硬件设备越多，耗时就越长。那么相关技术中的***休眠唤醒方案，因冻结任务及休眠设备、唤醒设备的过程耗时较 长，可导致***的休眠过程及唤醒过程的耗时过长，休眠唤醒速度较慢的问题。
而***的休眠过程及唤醒过程的耗时越长，该休眠唤醒过程的功耗就越大。而且，休眠唤醒过程耗时越长，还可导致休眠唤醒(例如亮灭屏)的响应时间过长，影响用户体验。此外，***的休眠、唤醒的速度较慢，可导致电子设备的待机时长缩短。
为此，本申请提供了一种操作***的休眠及唤醒方法，可通过CPU提频来提升操作***的休眠及唤醒过程的速度，以及降低休眠及唤醒过程的耗时时长。以及通过减少冻结任务数量和减少休眠唤醒设备数量的方式，来缩短操作***的休眠及唤醒过程的耗时时长，从而缩短电子设备的休眠唤醒(例如亮灭屏)的响应时间，以提升用户体验，以及降低***的功耗开销。且***休眠及唤醒过程的速度提升，可延长电子设备的待机时长。
示例性的，本申请休眠唤醒的操作***所安装至的电子设备可以为蜂窝电话(cellular phone)，平板电脑(pad)、可穿戴设备或物联网设备、座舱域控制器(CDC，Cockpit Domain Controller)等，本申请对此不做限制。
下面对本申请涉及的技术名词进行解释：
计算机***中，在电源管理模块上CPU从高一级的活跃状态下调为不活跃状态为休眠；收到信号使***重新运行为唤醒。本申请的各实施例，以***休眠过程为进入到S3状态，以***唤醒过程为进入到S0状态为例进行说明。
功耗：指的是在单位时间中所消耗的能源的数量，单位为W。
提频：是指提高CPU的运行频率，从而提高CPU的性能。
冻结任务：将任务的状态设置为停止状态，以暂停任务的运行，冷冻后的任务无法产生数据，也不会与任何模块进行交互，冻结后的任务的任务状态为freeze(冻结)状态。
解冻任务：将任务的状态从冻结状态恢复设置为运行状态，以使该任务可从被冻结时刻时的任务状态开始继续执行，解冻后的任务可产生数据，可与其他模块进行交互。
示例性的，任务1在t1时刻冻结，使得任务1的全部数据及操作均在t1时刻暂停执行。在任务1在t2时刻解冻后，任务1的全部数据及操作可在t2时刻开始继续执行。其中，t2时刻在t1时刻之后。
示例性的，本申请各个实施例所述的任务可包括但不限于：线程或进程。
核心设备：可影响CPU运行的设备，示例性的，核心设备可包括位于CPU内部的硬件设备。
外挂设备(简称外设)：不会影响CPU运行的设备，***中可包括外挂设备的设备列表。示例性的，外挂设备可包括但不限于：鼠标、键盘、打印机等。
图2a为示例性示出的本申请的主机的微内核架构示意图，图2b可为本申请的***的软件架构示意图。
下面结合图2a和图2b对本申请的***进行描述，如图2a所示，本申请的主机可分为多层架构，包括应用层、框架服务层、内核层以及硬件层。
示例性的，应用层和框架服务层可实现在用户态，内核层和硬件层可实现在内核态。
示例性的，应用层可包括至少一个应用程序，这里示例性地示出了应用1至应用n。
示例性的，应用层可接收用户输入。
示例性的，框架服务层(又称，微内核服务层，或微内核的用户态基础服务)可包括但不限于：电源管理模块(又称电源管理服务)、驱动框架模块等。这里仅示例性的示出了框架服务层中的两个服务模块，该服务框架层还可包括更多的服务模块，这里不做限制。
本申请实施例的操作***实现在微内核架构下，框架服务层中涉及的各个功能模块，可通过从内核态移植到微内核架构下的用户态的方式，来将功能以应用的方式来向用户提供相应服务。
示例性地，电源管理模块，可用于电源管理等。
示例性地，驱动框架模块，可用于运行各个硬件设备的驱动程序。
示例性的，内核层可包括内核处理模块和内核中断子***。
示例性的，硬件层可包括多核CPU，多核CPU可包括主核CPU和至少一个从核CPU(这里示例性示出一个从核CPU)。此外，硬件层还可包括核心设备与外挂设备，关于两类设备的定义可参照上文，这里不再赘述。
结合图2a的微内核架构，操作***中的任务可分为用户态任务和内核态任务。
示例性的，用户态任务为运行在用户态的任务(例如进程、线程等)。
示例性的，用户态任务可包括普通任务以及用户态的***服务任务。
示例性的，普通任务：用户触发操作而创建的任务，例如用户对图2a中用户态的位于应用层的应用或位于框架服务层中的服务触发操作，而创建的任务。
例如用户对音乐应用(例如图2a的应用层中的一个应用)触发播放音乐的操作，***响应于该用户操作而创建播放音乐的任务为普通任务。
示例性的，用户态的***服务任务：由图2a所示的框架服务层中的各服务模块触发(而非用户触发)的***任务。例如用于显示手机桌面界面的任务。
示例性的，内核态任务为运行在内核态的***任务，本申请的微内核架构下，内核层的开销较低。
在本申请各实施例中，***任务可包括用户态的***服务任务，以及内核态的***任务。
需要说明的是，图2a示出的应用层、框架服务层，内核层、硬件层并不构成对设备的具体限定。在本申请另一些实施例中，设备可以包括比图示更多或更少的层级，以及，以及各层可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图2a中所示出的各种层级、各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
图2b为示例性示出的本申请的操作***的休眠和唤醒的过程示意图。图2b中左半部分为操作***休眠过程的示意图，图2b中右半部分为操作***唤醒过程的示意图。
结合图2a，请参照图2b，示例性的，电源管理模块(也称休眠唤醒管理模块)可包括但不限于：图2b所示的CPU提频维持模块、快速冻结任务模块、快速休眠设备模块、从核提频维持模块、快速唤醒设备模块、解冻任务模块，可选地包括CPU提频解除模块。
结合图2a，请参照图2b，示例性的，内核处理模块(也称核心处理模块)可包括但 不限于：图2b所示的从核下线模块、休眠核心设备模块、主核下线模块、主核上线模块、唤醒核心设备模块、从核上线模块。
相关技术中图1所示的***应用于内核架构下的操作***，本申请的图2b所示的***不仅可应用于内核架构下的操作***(例如Linux操作***)，还可应用于图2a所示的微内核架构下的操作***，后文以本申请的***应用于微内核架构下的操作***为例进行说明，在本申请的***应用于内核架构下的操作***时，原理类似，不再一一赘述。
对比于图1，如图2b所示，本申请的***新增了以下软件模块：CPU提频维持模块、从核提频维持模块、快速冻结任务模块、快速休眠设备模块、快速唤醒设备模块，可选地还包括CPU提频解除模块。上述模块可构成与图1所示的方案的主要区别，但是，对于图2b中的其他模块，同样与图1中的相应模块存在区别，具体区别下文将详细阐述。
示例性的，CPU提频维持模块、从核提频维持模块，可实现CPU精准提频机制，具体可用于获取***休眠或唤醒请求，并判断该请求是否为预设请求(预设休眠请求或预设唤醒请求)，如果该请求为预设请求(预设休眠请求或预设唤醒请求)，说明该请求与用户体验强相关，从而选择将CPU(主核CPU，和/或，从核CPU)的工作频率提高至最高工作频率，以提升CPU的指令执行速度，从而加速完成***休眠或唤醒流程；相反，如果该请求不为预设请求，则说明该请求不与用户体验强相关，则可将CPU的工作频率提高至最佳能效比的工作频率，以维持CPU功耗最低的休眠唤醒流程。
示例性的，上述CPU精准提频机制可以看做本申请提供的一种CPU提频策略，该CPU提频策略，在***休眠或***唤醒过程中可被触发。
示例性的，预设休眠请求为与用户体验相关的休眠请求。预设唤醒请求为与用户体验相关的唤醒请求。示例性的，与用户体验相关的请求可为在用户希望***休眠(或唤醒)过程的速度更快、耗时更短的场景下的***休眠请求。
示例性的，在所述CPU的工作频率为最佳能效比的工作频率a时，所述CPU的能效比最高。可以理解的是，在CPU处于不同工作频率下，来完成相同量的指令执行任务时，其中，该CPU的工作频率为该工作频率a时，该CPU的功耗最低。因此，可将该工作频率a命名为该CPU的最佳能效比的工作频率。
示例性的，快速冻结任务模块，可实现快速冻结任务机制，在该机制下，无需等待阻塞任务，可选地无需冻结***任务，减少冻结任务数量，以实现任务的快速冻结，从而加速***休眠过程。
示例性的，快速冻结任务模块在过滤任务时，对于阻塞状态的任务的过滤步骤，与对于***任务的过滤步骤的执行顺序不做限制。可选地，首先过滤***任务，得到普通任务，然后，对普通任务中处于阻塞状态的任务进行过滤，只对处于非阻塞状态的普通任务进行冻结，以加速任务冻结。
示例性的，快速冻结任务模块也可直接识别普通任务，然后，对普通任务中处于阻塞状态的任务进行过滤，从而只对处于非阻塞状态的普通任务进行冻结，以加速任务冻结。
示例性的，快速休眠设备模块、快速唤醒设备模块，可结合运行时休眠唤醒机制，在***运行时，对外挂设备的状态(休眠状态或唤醒状态)进行管理记录。那么在需要 休眠或唤醒***时，可基于记录的外挂设备的状态，来减少待休眠或待唤醒的外挂设备的节点个数，以快速休眠、唤醒设备，从而加速***休眠、唤醒过程。
示例性的，CPU提频解除模块，可用于在解冻任务之后，将CPU的调频策略，恢复为原调频策略；其中，所述原调频策略为在接收到所述***唤醒请求之前，所述CPU的调频策略。
示例性的，这里的CPU为在***休眠或唤醒过程中，已使用本申请的提频策略进行提频的CPU，可以是主核CPU或从核CPU，本申请不做限制。
示例性的，本申请对CPU的原调频策略不做限制，该原调频策略为在进入***休眠或唤醒流程的本申请的提频操作之前，该CPU的调频策略。
示例性的，原调频策略可为固定调频策略，即将CPU的工作频率调整至该策略配置的固定工作频率。示例性的，原调频策略也可以为动态调频策略，即根据CPU上运行的任务，来灵活调整CPU的工作频率。
图2b所示的本申请***中的各个模块及通信连接关系仅是一个范例，本申请的***可以具有比图中所示的更多的或者更少的模块，可以合并组合两个或多个的模块，或者可以具有不同的模块配置。图2b中所示出的各种模块可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
图2c为图2a中部分部件在执行***休眠或***唤醒的过程的交互示意图。
需要说明的是，图2c对不同模块之间的交互以单方向箭头示出，在具体应用中，不同模块之间可存在双方向的交互通信，这里不再赘述。
下面结合图2c对图2b中的各模块的工作流程进行阐述。
实施例1，***休眠流程：
步骤11、接收***休眠请求。
示例性的，如图2c所示，电源管理模块可从应用层或内核中断子***，接收到***休眠请求。
示例性的，该***休眠请求可以是***触发的预设事件，或用户在应用层触发的预设事件。
本申请的***休眠方法可应用于手机等电子设备的***休眠场景，也可以应用到机动车的***休眠场景，以及其他电子设备的休眠场景，本申请对此不做限制。
示例性的，该***休眠请求由用户在应用层触发时，则电源管理模块可从应用层接收到用户触发的***休眠请求。
例如，本申请的***应用于手机，用户按压手机的锁屏按键可触发该***休眠请求，其中，用户希望快速灭屏，那么这里的***休眠请求为与用户体验强相关的预设休眠请求。可以理解的是，与用户体验强相关的预设休眠请求并不限于这里的举例。
例如，本申请的***可应用于机动车场景下的CDC，机动车长时间没有移动，且用户长时间没有对机动车的显示屏进行任何操作，则***可触发***休眠请求，以休眠机动车***。这里的***休眠请求不属于与用户体验强相关的预设休眠请求。
示例性的，在机动车场景下，CDC可分为仪表域和娱乐域。示例性的，预设休眠请求可包括与仪表域、或娱乐域的显示相关的休眠请求。
示例性的，该***休眠请求由***触发时，则电源管理模块可从中断子***接收到***休眠请求。
例如，本申请的***可应用于手机，手机长时间亮屏、且手机没有接收到用户触发的任何输入，则中断子***定时发送***休眠请求至电源管理模块，以使电源管理模块从中断子***接收到***触发的***休眠请求。其中，用户不关心该休眠过程的速度快与慢，那么该***休眠请求不属于与用户体验强相关的预设休眠请求。
需要说明的是，***休眠请求是否为与用户体验强相关的预设休眠请求的考量标准，并不限制为用户在应用层触发的***休眠请求就一定是预设休眠请求，也不限制为由中断子***自动发出的***休眠请求就一定不是预设休眠请求，***休眠请求是否为预设休眠请求，与该***休眠请求的触发对象无直接关联性。
示例性的，如图2b所示，电源管理模块中的CPU提频维持模块可接收到应用层发送的***休眠请求，或CPU提频维持模块可接收到内核中断子***发送的***休眠请求。
步骤12、CPU提频。
示例性的，如图2c所示的电源管理模块(例如图2b所示的CPU提频维持模块)，可基于该***休眠请求是否为预设休眠请求，确定对CPU待提频至的目标频率(最高工作频率或最佳能效比的工作频率)。
在一种可能的实施方式中，在多核CPU的场景下，多核CPU可分为多组CPU。例如8核CPU可包括两组4核CPU，其中，一组4核CPU中各CPU的工作频点接近。那么CPU提频维持模块在确定对CPU待提频至的目标频率时，可对每组CPU的工作频率分别确定目标频率，同一组CPU的目标频率相同。例如目标频率为该组CPU对应的最高工作频率，或最佳能效比的工作频率。
在另一种可能的实施方式中，在多核CPU的场景下，各单核CPU的工作频率可单独控制，那么CPU提频维持模块在确定对CPU待提频至的目标频率时，可对各单核CPU分别确定目标频率，各核CPU的目标频率相互独立。例如一个单核CPU的目标频率为该单核CPU的最高工作频率，或最佳能效比的工作频率。
需要说明的是，在多核CPU场景下，多核CPU包括一个主核CPU和至少一个从核CPU，本申请对于不同从核CPU的下线顺序以及提频顺序不做限制，但是从核CPU均在主核CPU下线之前下线。
示例性的，在休眠流程中，对需要下线的CPU，在下线该CPU之前，本申请的***可首先提高其工作频率，以使该CPU可以较高的工作频率来冻结该CPU上运行的任务，以加速***休眠过程，缩短休眠过程的时长。
在一种可能的实施方式中，如图2c所示的电源管理模块(例如图2b所示的CPU提频维持模块)，可将待提频的CPU以及该CPU待提频至的目标频率的信息，通知至内核处理模块。内核处理模块可向主核CPU发送指令，以提高主核CPU和/或从核CPU的工作频率至相应的目标频率。
示例性的，待提频的CPU可包括主核CPU和/或从核CPU，本申请对此不做限制。
示例性的，如图2c所示，主核CPU可对从核CPU提频。示例性的，内核处理模块可向主核CPU发送第一指令，以由主核CPU来将从核CPU的工作频率提高至相应的目标频 率。
示例性的，内核处理模块也可以向主核CPU发送第二指令，以使主核CPU将主核CPU的工作频率提高至相应的目标频率。
第一指令与第二指令可以相同或不同，本申请对此不做限制。本实施方式中，主核CPU可对从核CPU进行提频。
在另一种实施方式中，电源管理模块(例如图2b所示的CPU提频维持模块)也可以将待提频的CPU的信息以及对该CPU待提频至的目标频率的信息，通知至图2a所示的核心设备驱动模块，以使核心设备驱动模块来将主核CPU和/或从核CPU的工作频率提高至相应的目标频率。示例性的，主核CPU同样可对从核CPU的工作频率提频至相应的目标频率。示例性，核心设备驱动模块可包括核心设备的驱动程序。
步骤13，任务冻结。
示例性的，在步骤12之后，如图2c所示的电源管理模块(例如图2b所示的快速冻结任务模块)，可基于快速冻结任务机制，对操作***中的任务(例如操作***中的所有任务)进行过滤。示例性的，电源管理模块，可对操作***中的所有任务，过滤处于阻塞状态的普通任务，以及过滤***任务(包括用户态的***服务任务和内核态的***任务)。并且，电源管理模块可借助于内核处理模块，来控制主核CPU和/或从核CPU，来对相应CPU上执行的未处于阻塞状态的普通任务进行冻结，可减少冻结任务的数量，从而实现任务的快速冻结。
可选地，在一种可能的实施方式中，在步骤13中，当本申请的***应用于内核架构下的操作***时，例如应用于Linux操作***，则电源管理模块可基于快速冻结任务机制，对操作***中的任务(例如操作***中的所有任务)，过滤处于阻塞状态的任务。并且，电源管理模块可借助于内核处理模块，来控制主核CPU和/或从核CPU，来对相应CPU上执行的未处于阻塞状态的任务进行冻结。该过程中，无需对处于阻塞状态的任务进行冻结，可减少冻结任务的数量，从而实现任务的快速冻结。
步骤14，休眠非核心设备。
示例性的，在步骤13之后，如图2c所示的电源管理模块(例如图2b所示的快速休眠设备模块)，可结合运行时休眠唤醒机制，以在进入图2b所示的***休眠或***唤醒的流程之前，对非核心设备(例如外挂设备)是否处于休眠状态或唤醒状态进行管理。从而可在进入图2b所示的***休眠流程时，电源管理模块无需对处于休眠状态的外挂设备进行遍历，可减少对用于休眠设备的第一回调函数的调用数量，从而加速休眠设备的过程。其中，一个设备可对应有一个用于休眠该设备的第一回调函数。
示例性的，示例性的，图2c所示的外设模块可包括相应外挂设备的驱动，如图2c所示，电源管理模块在对遍历的外挂设备进行休眠时，电源管理模块可调用外设模块，以休眠相应的外挂设备。示例性的，电源管理模块可调用相应设备的驱动的第一回调函数，以休眠相应的外挂设备。
步骤15，下线从核CPU。
示例性的，在步骤14之后，如图2c所示的电源管理模块(例如图2b所示的快速休眠设备模块)，可通知内核处理模块(例如图2b所示的从核下线模块)来对至少一个从 核CPU进行下线。当然，在对某个CPU下线时，电源管理模块通知内核处理模块的信息并不限于这里的举例，还可包括更多的信息，这里不做限制。
示例性的，内核处理模块可将该从核CPU上运行的所有内核态任务(例如内核态线程)进行冻结，并控制该从核CPU进行下线等操作。
步骤16，休眠核心设备。
示例性的，在步骤15之后，如图2c所示的内核处理模块(例如图2b所示的休眠核心设备模块)可对核心设备进行休眠(例如关闭)。
步骤17，下线主核CPU。
示例性的，在步骤16之后，如图2c所示的内核处理模块(例如图2b所示的主核下线模块)，可将该主核CPU上运行的所有内核态任务(例如内核态线程)进行冻结，并控制该主核CPU进行下线等操作。
在本实施例中，可通过上述步骤11至步骤17来实现对操作***的休眠，可对CPU进行提频，从而利用提频后的CPU来处理休眠过程的指令，以加速***休眠过程；以及在冻结任务时，无需对处于阻塞状态的任务进行冻结，可减少任务冻结数量，可选地还可过滤***任务，从而只对未处于阻塞状态的普通任务进行冻结，可进一步减少任务冻结数量，从而加速任务冻结速度；以及可在***运行过程中，基于设备的状态变化，而对设备状态进行管理，那么在休眠非核心设备时，可减少对待休眠设备的遍历数量，从而加速设备休眠过程。基于上述过程可缩短***休眠过程的时长，提升***休眠速度，以提升用户体验和降低功耗。
实施例2，***唤醒流程：
步骤21、接收***唤醒请求。
示例性的，如图2c所示，电源管理模块可从应用层或内核中断子***，接收到***唤醒请求。
示例性的，该***休眠请求可以是***触发的预设事件，或用户在应用层触发的预设事件。
本申请的***唤醒方法可应用于手机等电子设备的***唤醒场景，也可以应用到机动车的***唤醒场景，以及其他电子设备的唤醒场景，本申请对此不做限制。
示例性的，如图2c所示，在***休眠之后，电源管理模块可接收到应用层发送的***唤醒请求，或电源管理模块可接收到内核中断子***发送的***唤醒请求。
示例性的，该***唤醒请求由用户在应用层触发时，则电源管理模块可从应用层接收到用户触发的***唤醒请求。
例如，本申请的***应用于手机，用户按压手机的锁屏按键可触发该***唤醒请求，其中，用户希望快速亮屏，那么这里的***唤醒请求为与用户体验强相关的预设唤醒请求。
例如，本申请的***可应用于机动车场景下的CDC，在机动车CDC的***休眠后，用户按压机动车的启动引擎按钮，则电源管理模块可接收到用户触发的***唤醒请求，以唤醒机动车的操作***。这里的***唤醒请求为与用户体验强相关的预设唤醒请求。
示例性的，该***唤醒请求由***触发时，则电源管理模块可从中断子***接收到***唤醒请求。
例如，本申请的***可应用于手机，例如手机***休眠后，手机***可周期性的发送用于唤醒***的心跳指令，以执行相关操作，这里的心跳指令不属于与用户体验强相关的预设唤醒请求，因为，用户并不关心该唤醒过程的速度。且，该唤醒过程对用户是无感知的。
需要说明的是，***唤醒请求是否为与用户体验强相关的预设唤醒请求的考量标准，并不限制为用户在应用层触发的***唤醒请求就一定是预设唤醒请求，也不限制为由中断子***自动发出的***唤醒请求就一定不是预设唤醒请求，***唤醒请求是否为预设唤醒请求，与该***唤醒请求的触发对象无直接关联性。
步骤22、上线主核CPU。
示例性的，参照图2c，电源管理模块可将接收到的***唤醒请求通知至内核处理模块。示例性的，如图2b所示，内核处理模块中的主核上线模块可接收到***唤醒请求(例如用于唤醒***的中断信号)。如图2c所示，内核处理模块可控制主核CPU进行上线等操作。
步骤23、唤醒核心设备。
示例性的，在步骤22之后，如图2c所示的内核处理模块(例如图2b所示的唤醒核心设备模块)可对核心设备进行唤醒(例如启动运行)。
步骤24，上线从核CPU。
示例性的，在步骤23之后，如图2c所示的内核处理模块(例如图2b所示的从核上线模块)可对至少一个从核CPU进行上线。
步骤25，CPU提频。
示例性的，在步骤24之后，如图2c所示的电源管理模块(例如图2b所示的从核提频维持模块)，可基于从应用层或内核中断子***接收到的该***唤醒请求，是否为预设唤醒请求，来确定对已上线的从核CPU待提频至的目标频率(最高工作频率或最佳能效比的工作频率)。
示例性的，已上线的从核CPU的数量为至少一个，在已上线的从核CPU的数量为多个时，电源管理模块可对每个从核CPU，分别确定待提频至的目标频率(最高工作频率或最佳能效比的工作频率)，也可以对多个从核CPU，确定共同的一个待提频至的目标频率(最高工作频率或最佳能效比的工作频率)。
示例性的，当该***唤醒请求为预设唤醒请求时，则该目标频率为相应从核CPU的最高工作频率，当该***唤醒请求不为预设唤醒请求时，则该目标频率为相应从核CPU的最佳能效比的工作频率。
示例性的，在唤醒流程中，在唤醒非核心设备以及解冻任务之前，可对上线的从核CPU提高其工作频率，以使该从核CPU可以较高的工作频率，来唤醒非核心设备，以及解冻任务，以加速***唤醒过程，缩短唤醒过程的时长。
在一种可能的实施方式中，如图2c所示的电源管理模块(例如图2b所示的从核提频维持模块)，可将待提频的CPU以及该CPU待提频至的目标频率的信息，通知至内核处 理模块。内核处理模块可向主核CPU发送指令，以提高相应从核CPU的工作频率至相应的目标频率。
示例性的，如图2c所示，主核CPU可对从核CPU提频。示例性的，内核处理模块可向主核CPU发送第一指令，以由主核CPU来将从核CPU的工作频率提高至相应的目标频率。
在另一种实施方式中，电源管理模块(例如图2b所示的从核提频维持模块)也可以将待提频的CPU以及对该CPU待提频至的目标频率的信息，通知至图2a所示的核心设备驱动模块，以使核心设备驱动模块来将相应从核CPU的工作频率，提高至相应的目标频率。
本步骤25的执行原理，与休眠流程中的步骤12的原理类似，这里不再一一赘述。
步骤26，唤醒非核心设备。
示例性的，在步骤25之后，如图2c所示的电源管理模块(例如图2b所示的快速唤醒设备模块)，可结合运行时休眠唤醒机制，以在进入图2b所示的***休眠或***唤醒的流程之前，对非核心设备(例如外挂设备)是否处于休眠状态或唤醒状态进行管理。从而可在进入图2b所示的***唤醒流程时，电源管理模块无需对处于唤醒状态的外挂设备进行遍历，可减少对用于唤醒设备的第二回调函数的调用数量，从而加速唤醒设备的过程。其中，一个设备可对应有一个用于唤醒该设备的第二回调函数。
示例性的，示例性的，图2c所示的外设模块可包括相应外挂设备的驱动，如图2c所示，电源管理模块在对遍历的外挂设备进行唤醒时，电源管理模块可调用外设模块，以唤醒相应的外挂设备。示例性的，电源管理模块可调用相应设备的驱动的第二回调函数，以唤醒相应的外挂设备。
步骤27，解冻任务。
示例性的，在步骤26之后，如图2c所示的电源管理模块(例如图2b所示的解冻任务模块)，可通过内核处理模块，来对处于冻结状态的任务进行解冻，以恢复相应任务的运行。
示例性的，这里处于冻结状态的任务，在冻结时未处于阻塞状态。
示例性的，这里处于冻结状态的任务为普通任务。
示例性的，这里解冻的任务可为实施例1中步骤13冻结的任务。
可选地，步骤28，解除CPU提频。
示例性的，在步骤26之后，如图2c所示的电源管理模块(例如图2b所示的CPU提频解除模块)，可在解冻任务之后，将CPU的调频策略，恢复为原调频策略；其中，所述原调频策略为在接收到所述***唤醒请求之前，所述CPU的调频策略。
示例性的，这里的CPU为在***休眠或唤醒过程中，已使用本申请的提频策略进行提频的CPU，可以是主核CPU或从核CPU，本申请不做限制。
示例性的，本申请对CPU的原调频策略不做限制，该原调频策略为在进入***休眠或唤醒流程的本申请的提频操作之前，该CPU的调频策略。
示例性的，原调频策略可为固定调频策略，即将CPU的工作频率调整至该策略配置的固定工作频率。示例性的，原调频策略也可以为动态调频策略，即根据CPU上运行的 任务，来灵活调整CPU的工作频率。
示例性的，电源管理模块可在确定需要对相应从核CPU的工作频率进行调节时，可将该从核CPU待调节至的频率通知至图2c所示的内核处理模块。那么内核处理模块可通知主核CPU以对从核CPU的工作频率进行调节，或者，内核处理模块可通知从核CPU来对该从核CPU的工作频率进行自调节，本申请对此不做限制。
在本实施例中，可通过上述步骤21至步骤28来实现对操作***的唤醒，可对CPU进行提频，从而利用提频后的CPU来处理唤醒过程的指令，以加速***唤醒过程；以及可在***运行过程中，基于设备的状态变化，而对设备状态进行管理，那么在唤醒非核心设备时，可减少对待唤醒设备的遍历数量，从而加速设备唤醒过程。基于上述过程可缩短***唤醒过程的时长，提升***唤醒速度，以提升用户体验和降低功耗。
图3a为示例性示出的一种***休眠过程的示意图。
图3a以机动车的CDC为应用场景，本示例中，CDC分为仪表域和娱乐域，其中，仪表域为微内核架构(例如图2a所示的微内核架构)，本申请的***可运行在嵌入式平台。
如图3a所示，该***休眠过程可包括如下步骤：
S501，电源管理模块接收***休眠请求并处理。
示例性的，电源管理模块可参照图4a所示的实现过程，通过CPU精准提频机制来实现S501。
示例性的，如图4a所示，电源管理模块对该CPU精准提频机制的实现过程可包括：
S101，电源管理模块接收***休眠请求。
S102，电源管理模块判断***休眠请求是否为预设请求。
例如，用户按压机动车的显示屏上的休眠按键，则电源管理模块可从应用层接收到用户触发的***休眠请求，以休眠机动车的操作***。这里的***休眠请求为与用户体验强相关的预设休眠请求。
例如，机动车长时间没有移动，且用户长时间没有对机动车的显示屏进行任何操作，则电源管理模块可接收到图2c所示的中断子***发送的***休眠请求，以休眠机动车***。这里的***休眠请求不属于与用户体验强相关的预设休眠请求。
示例性的，***休眠请求的形式可以是事件，那么电源管理模块可配置表示预设休眠请求的第一预设事件，那么在触发的***休眠的事件为第一预设事件时，则可转至执行S103，那么在触发的***休眠的事件不为第一预设事件时，则可转至执行S104。
S103，电源管理模块在检测到***休眠请求为预设请求时，可确定对CPU待提频的目标频率为最高工作频率。
示例性的，预设请求可包括预设休眠请求。
例如，在用户按压机动车的显示屏上的休眠按键后，用户希望机动车***尽快进入休眠状态，那么电源管理模块可确定待提频的CPU以及该CPU待提频至的目标频率，这里为该CPU的最高工作频率。
示例性的，电源管理模块可配置有各单核CPU或各组CPU(包括多核CPU)的最高工作频率。
S104，电源管理模块在检测到***休眠请求不是预设请求时，可确定对CPU待提频的目标频率为最佳能效比的工作频率。
例如，机动车长时间没有移动，且用户长时间没有对机动车的显示屏进行任何操作，则电源管理模块可接收到图2c所示的中断子***发送的***休眠请求，以休眠机动车***。电源管理模块检测到这里的***休眠请求不属于与用户体验强相关的预设休眠请求，可确定待提频的CPU以及将该CPU待提频至的目标频率为该CPU的最佳能效比的工作频率。
示例性的，各CPU的最佳能效比的工作频率是与CPU的硬件强相关的。各CPU的最佳能效比的工作频率，可基于具体的芯片平台的CPU，在各工作频率下的功耗测试数据而确定。
图4b为示例性示出的一种CPU的工作频率与电池的电流的测试数据的曲线图。
如图4b所示，最佳能效比的工作频率为图4b中圆圈所示的功耗拐点频率(例如，这里为918MHz)。
需要说明的是，图4b中横轴与纵轴中各数值并不用于限制本发明，这里只是将功耗测试数据示例性示出，而并不用于限制本申请。且本申请，对于图4b中的各工作频率下的电流的具体取值不做限制。
示例性的，***中各CPU的最佳能效比的工作频率可为先验数据，电源管理模块可配置有各单核CPU或各组CPU(包括多核CPU)的最佳能效比的工作频率。
S502，电源管理模块通过设备驱动模块对CPU提频。
示例性的，图3a中的设备驱动模块可包括图2a所示的核心设备驱动模块。
示例性的，电源管理模块可以将待提频的CPU的信息以及对该CPU待提频至的目标频率(最高工作频率或最佳能效比的工作频率)的信息，通知至设备驱动模块中的核心设备驱动模块，以使核心设备驱动模块来将主核CPU和/或从核CPU的工作频率提高至相应的目标频率。
示例性的，在该***休眠请求与用户体验相关(例如***休眠请求为预设休眠请求)时，则本申请的***可将CPU的工作频率提高至其最高工作频率，以最大程度保障***休眠过程的用户体验；在该***休眠请求与用户体验不相关时(例如***休眠请求不为预设休眠请求)，则本申请的***可将CPU的工作频率调整至最佳能效比的工作频率，以最大程度节省CPU的功耗。
对于S501和S502的具体实现细节，可参照实施例1的步骤11和步骤12，原理类似，这里不再赘述。
S503，电源管理模块通过内核处理模块冻结普通任务。
示例性的，电源管理模块可参照图5a、图5b所示的实现过程，通过快速冻结任务机制来实现S503。
示例性的，如图5a所示，电源管理模块对该快速冻结任务机制的实现过程可包括如下步骤：
S201，电源管理模块遍历普通任务，并向普通任务发送冻结信号。
示例性的，在微内核架构下，电源管理模块可遍历***中的***任务进行过滤，而 仅遍历普通任务，无需遍历***任务(可包括用户态的***服务任务和内核态的***任务)，并向遍历的普通任务发送冻结信号，使得***中的每个普通任务均可接收到冻结信号以进行普通任务的冻结。
示例性的，在内核架构下(例如Linux操作***)，电源管理模块无需过滤***任务，只需过滤处于阻塞状态的任务(包括***任务和普通任务)，可加速任务冻结过程。其他关于冻结任务的过程，与本申请各实施例描述的冻结任务的过程类似，这里不再赘述。
示例性的，普通任务和***任务为两种类型的任务，可通过任务标识来进行区分识别。
示例性的，普通任务在接收到冻结信号后，可选地，普通任务可将本普通任务标记为冻结状态。普通任务接收到冻结信号后，或普通任务具有该冻结状态的标记后，在普通任务不处于阻塞状态时，普通任务可冻结自己。在冻结普通任务时，普通任务可发送冷冻指令至CPU，CPU执行该冻结指令，以冻结该普通任务，使得该普通任务的状态(例如运行状态)更新为冻结状态。
可选地，例如普通任务在接收到冻结信号时，该普通任务正在写数据。那么普通任务可在执行完本次写数据的操作之后，普通任务再发送冻结指令至CPU，以冻结该普通任务。
S202，电源管理模块遍历普通任务并检查普通任务的任务状态。
示例性的，在S202之后，电源管理模块可继续遍历***中的所有普通任务，并检查遍历到的普通任务的任务状态。
S203，电源管理模块判断任务状态是否为阻塞状态。
可选地，电源管理模块检测到任务状态为阻塞状态，则电源管理模块执行S204。
可选地，S204，电源管理模块将处于阻塞状态的普通任务添加到阻塞任务链表。
示例性的，处于阻塞状态的任务，说明该任务在等待运行，那么处于阻塞状态的任务未处于运行状态，则为了缩短冻结任务的时长，本申请的***无需对处于阻塞状态的普通任务进行冻结。
可选地，电源管理模块也可以将处于阻塞状态的普通任务过滤，而不保存在数据结构(例如上述阻塞任务链表)中。
示例性的，电源管理模块可实现有任务冻结过滤器，电源管理模块可通过任务冻结过滤器，来对普通任务中处于阻塞状态的任务进行过滤，以加速任务冻结过程。可选地，电源管理模块可将过滤的处于阻塞状态的任务添加到阻塞任务链表(一种链表)。
示例性的，在***中可存在大量处于阻塞状态的任务，使得处于阻塞状态的任务的数量占比相对较大，考虑到阻塞状态的任务不参与任务调度。那么本申请的***可通过对阻塞状态的任务进行过滤，而不对阻塞状态的任务进行是否处于冻结状态的判断，也不需要对处于阻塞状态的任务进行冻结，从而可大幅提高冻结任务的整体效率，以及加速冻结任务的过程。
可选地，电源管理模块可对所有普通任务发送冻结信号，那么普通任务中处于阻塞状态的任务同样可接收到冻结信号，那么如果在进入休眠非核心设备(例如外设)的步骤之前，该阻塞状态的任务的状态切换为非阻塞状态，由于该任务已经接收到了冻结信 号，那么该任务可首先处理冻结信号，以使该任务进入冻结状态，从而可避免阻塞状态的任务切换为非阻塞状态后，该任务未被冻结而影响***休眠的情况。
可选地，为了防止处于阻塞状态的任务(例如添加到阻塞任务链表中的任务)，在***休眠非核心设备之前(例如进入图3a的S504之前)切换为非阻塞状态(例如唤醒)，从而导致原本阻塞的任务得到运行的情况。在本申请实施例中，在下线从核CPU之前，内核处理模块不会将从核CPU上的定时器(timer)，以及从核CPU上的任务迁移到其他在线的CPU上。
这样，阻塞任务链表中运行在从核CPU上的任务，不会迁移到运行的CPU上。那么在从核CPU下线之后，从核CPU上的位于阻塞任务链表中的任务，即便从阻塞状态更新为非阻塞状态，该任务也不会被执行，从而确保在休眠非核心设备之前，阻塞任务链表中处于阻塞状态的任务的状态，即便更新为非阻塞状态，该任务也会按照接收到的冻结信号进行冻结状态，而无法运行。示例性的，例如从核CPU上的定时器的任务为阻塞状态，而被添加到阻塞任务链表，在该定时器定时结束后，该定时器对应的任务可发送中断至该从核CPU。但是，由于从核CPU已下线，该定时器对应的任务也没有迁移到其他运行的CPU上，使得***进入内核后，不会再接收到已下线的从核CPU的任务发起的中断，从而不会执行阻塞后唤醒的任务，保证阻塞任务不冻结正确性。
可选地，在执行下线从核CPU的步骤之前，例如在执行图3a中的S505之前，电源管理模块可检查阻塞任务链表中任务的任务状态，确定阻塞任务链表中是否存在处于运行状态的任务。例如阻塞任务链表中处于阻塞状态的任务，在从核CPU下线之前，该任务被唤醒而从阻塞状态切换为运行状态，虽然该阻塞状态的任务预先已经接收到了冻结信号，但是阻塞状态的任务仍旧运行了，从而导致阻塞任务链表中存在唤醒后冻结失败的任务，那么本次休眠过程失败，可再重新执行一次***休眠过程(例如回到图3a中的S501，来由电源管理模块重新对接收到***休眠请求进行处理以及后续步骤)。相反，如果该阻塞任务链表中的任务没有处于运行状态的任务，则说明***可冻结，从而继续执行图3a中的下线从核CPU的步骤。在实际应用中，阻塞任务链表中存在唤醒后冻结失败的任务的情况极少，本实施例可作为一种异常处理和确保***休眠可靠性的方案。
另外，需要说明的是，在本申请的图5a的实施例中，电源管理模块首先遍历普通任务并向普通任务发送冻结信号，然后，电源管理模块再对普通任务中处于阻塞状态的任务进行过滤(这里为添加到链表中)。在其他实施例中，电源管理模块也可以先对普通任务过滤处于阻塞状态的任务，并将该阻塞状态的任务加入到链表中。然后，电源管理模块可遍历普通任务(包括阻塞任务链表中的任务)发送冷冻信号。本申请对于对阻塞状态的任务的过滤的步骤，和向普通任务发送冻结信号的步骤，之间的执行顺序不做限制。
在S203之后，电源管理模块检测到任务状态不为阻塞状态，则电源管理模块可执行S205。
S205，电源管理模块判断不为阻塞状态的任务，该任务的任务状态是否为冻结状态。
示例性的，电源管理模块可对处于非阻塞状态(例如任务状态不为阻塞状态)的普通任务，判断该普通任务是否已经冻结。
在S205之后，电源管理模块检测到未处于阻塞状态的任务(例如任务状态不为阻塞 状态)，该任务的任务状态为冻结状态，则转至S202，电源管理模块继续遍历下一个普通任务的任务状态。
示例性的，电源管理模块检测到处于非阻塞状态的普通任务已冻结(即任务状态为冻结状态)，则电源管理模块可继续遍历下一个普通任务的任务状态，以对遍历到的处于阻塞状态的任务进行过滤，或对遍历到的处于非阻塞状态的任务进行是否处于冻结状态的判断。
在S205之后，电源管理模块检测到未处于阻塞状态的任务，该任务的任务状态不是冻结状态，则电源管理模块执行S206。
S206，电源管理模块将该普通任务添加到未冻结任务链表。
示例性的，电源管理模块遍历的普通任务既不处于阻塞状态，也不处于冻结状态，那么说明通过上述S201对该普通任务发送冻结信号后，该普通任务还未处理该冻结信号以进行任务冻结。
例如该普通任务在接收到冻结信号时，正在执行写数据的操作，那么在写数据的操作完成之前，该普通任务仍旧处于运行状态。或者，CPU处于忙碌状态，使得CPU没有执行已接收到冻结信号的该普通任务，向CPU发送的冻结指令。
那么电源管理模块可将该未处于阻塞状态、且未处于冻结状态的普通任务，添加到未冻结任务链表(一种链表)中。
示例性的，未冻结任务链表不同于阻塞任务链表。示例性的，未冻结任务链表可用于缓存未处于冻结状态以及未处于阻塞状态的普通任务。示例性的，阻塞任务链表可用于缓存处于阻塞状态的普通任务。
示例性的，在电源管理模块执行图5a的过程，在电源管理模块对普通任务的任务状态遍历结束(例如图5a中S202的遍历过程结束)之后，如图5b所示，电源管理模块对该快速冻结任务机制的实现过程可继续包括以下步骤：
S301，电源管理模块循环遍历未冻结任务链表并检查任务状态。
示例性的，电源管理模块可在预设时长内，循环遍历未冻结任务链表并检查任务状态，从而避免未冻结任务链表中的任务长时间未冻结，而影响***休眠速度。
S302，电源管理模块判断任务状态是否为冻结状态。
在S302之后，电源管理模块检测到任务状态为冻结状态，则转至执行S303。
S303，电源管理模块将处于冻结状态的任务从未冻结任务链表中删除。
在S303之后，在未冻结任务链表不为空的情况下，则电源管理模块继续转至执行S301，以使电源管理模块继续遍历未冻结任务链表中的下一个任务，直至未冻结任务链表为空，结束流程。
那么在未冻结任务链表中还存在任务的情况下，S301可循环执行，直至未冻结任务链表为空，即全部处于非阻塞状态的普通任务均已冷冻而处于冷冻状态。
在本申请实施例中，电源管理模块可将遍历到的非阻塞且尚未冻结的普通任务加到未冻结任务链表中。在电源管理模块对所有普通任务的任务状态遍历一次之后，电源管理模块可对未冻结任务链表中的任务的任务状态进行循环遍历，直至未冻结任务链表中所有非阻塞状态的任务均已冻结。其中，电源管理模块在对未冻结任务链表进行循环遍 历时，待遍历到该未冻结任务链表中的任务处于冻结状态，则电源管理模块可将该任务从未冻结任务链表中删除。使得电源管理模块在对未冻结任务链表的循环遍历过程中，该未冻结任务链表越来越短，可避免对已冻结的大量任务的任务状态的冗余检查，在电源管理模块检查任务的状态是否为冻结状态时，该遍历检查过程的效率大幅提升，可加速任务冻结效率。
可选地，在S302之后，在电源管理模块检测到任务状态不为冻结状态，则转至执行S304。
可选地，S304，电源管理模块等待预设时长。
在S304之后，电源管理模块转至执行S301，以使电源管理模块继续遍历未冻结任务链表中的下一个任务，直至未冻结任务链表为空，结束流程。
示例性的，在电源管理模块遍历未冻结任务链表时，检测到该未冻结任务链表中的任务未处于冻结状态，则电源管理模块可等待预设时长(例如10毫秒)，以在延迟预设时长之后，再执行S301。那么电源管理模块延迟的预设时长内，可使执行该电源管理模块的指令的CPU可以空闲，从而能够使得CPU可执行未冻结任务链表中的任务的冻结指令，以冻结该任务。
需要说明的是，该预设时长可根据应用场景而灵活配置，这里不限于举例的10毫秒。
示例性的，预设时长的单位可为毫秒。
可以理解的是，S304主要是为了***休眠的可靠性保证，在实际应用场景中，在S302之后，可执行S303，而较少存在S304的情况。
在微内核架构下，本申请的***在进行***休眠过程时，可过滤***任务(包括用户态的***服务任务、内核态的***任务)，而只对用户态的普通任务进行冻结。示例性的，驱动相关的***任务的数量较多，约200个。通过过滤***任务而仅对普通任务进行冻结，可大幅减少冻结的任务的数量。此外，部分***任务是为普通任务进行服务的，那么在普通任务冻结后，则该部分***任务也就无法再运行，而使得部分***任务没有发生调度。那么在冻结任务时，通过对***任务进行过滤，可减少对未发生调度的任务的冻结操作，减少不必要的任务冻结操作。另外，另一部分***任务用于执行***休眠的后续操作，例如休眠设备、下线CPU等操作，那么这些***任务也无需进行冻结。因此，在微内核架构下，***休眠时，可将从核CPU下线，那么从核CPU上的任务将停止执行，使得仅剩运行在主核CPU上的***任务(例如用于下线从核CPU)。那么当***休眠过程的执行阶段进入内核态时，从核CPU上的***任务不会再发生调度，本申请的***无需对***任务进行冻结，只需冻结普通任务，可减少冻结任务的数量。
在一种可能的实施方式中，本申请的***可采用stop machine(停止机器)机制的最高优先级保证，可避免从核CPU下线后，***中的剩余任务(例如驱动相关的***任务)执行的稳定性问题(例如死锁等)。
S504，电源管理模块通过设备驱动模块休眠外挂设备。
示例性的，图6a为示例性示出的电源管理模块实现的运行时休眠唤醒机制的实现过程。电源管理模块可结合图6a实现的运行时休眠唤醒机制，来通过图6b所示的休眠外挂设备的过程，来实现S504。
示例性的，设备驱动模块可包括图2a所示的外设模块，以用于休眠或唤醒外挂设备。
示例性的，如图6a所示，电源管理模块对该运行时休眠唤醒机制的实现过程可包括：
S401，电源管理模块在***运行时，检测外挂设备是否处于运行状态。
示例性的，可在电源管理模块需要周期性遍历外挂设备时，来执行S401。或者，可在电源管理模块需要检测外挂设备的状态时，来执行S401。从而避免新增周期性或定时检测外挂设备的运行状态的步骤，以节省信令开销。
示例性的，电源管理模块可在开机后生成两个链表，链表1为已休眠链表，用于缓存处于休眠状态的外挂设备的信息(该信息用于标识外挂设备，例如设备标识)。链表2为已唤醒链表，用于缓存处于运行状态的外挂设备的信息(该信息用于标识外挂设备，例如设备标识)。在开机后，初始化的链表1和链表2均为空链表。
此外，由于在休眠或唤醒设备时，对设备有顺序依赖关系要求，因此需要在电源管理模块中记录各外挂设备之间的顺序依赖关系。
示例性的，电源管理模块可在链表1和链表2中分别记录各外挂设备之间的顺序依赖关系，例如以设备序号来表示设备之间的顺序依赖关系。
例如，设备A的运行依赖于设备B，则在***休眠时，首先对设备A进行休眠，然后再对设备B进行休眠。那么在已休眠链表中，设备A的设备序号为1，设备B的设备序号为2，其中，设备A的设备标识为A，设备B的设备标识为B。
例如，设备A的运行依赖于设备B，则在***唤醒时，首先对设备B进行唤醒，然后再对设备A进行休眠。那么在已唤醒链表中，设备B的设备序号为1，设备A的设备序号为2，其中，设备A的设备标识为A，设备B的设备标识为B。
示例性的，在链表1中存储各已休眠的外挂设备的标识信息时，可按照设备序号进行排序存储。
示例性的，在链表2中存储各已唤醒的外挂设备的标识信息时，可按照设备序号进行排序存储。
在一种可能的实施方式中，在电源管理模块检测到外挂设备处于运行状态时，可执行S402。
可选地，S402，电源管理模块调用该外挂设备的用于唤醒的回调函数。
可选地，S403，电源管理模块检测已休眠链表中是否包括该外挂设备的标识信息。
在S403之后，电源管理模块检测到已休眠链表中不包括该外挂设备的标识信息，则转至执行S405。
S405，电源管理模块将该外挂设备的标识信息写入已唤醒链表。
在S403之后，电源管理模块检测到已休眠链表中包括该外挂设备的标识信息，则转至执行S404。
S404，电源管理模块将该外挂设备的标识信息从已休眠链表转移至已唤醒链表。
在本实施例中，在***运行时，电源管理模块检测到任意外挂设备处于运行状态，则可调用外设模块中该外挂设备的用于唤醒的回调函数，以唤醒该外挂设备。此外，电源管理模块还可将该外挂设备的标识信息记录至已唤醒链表。示例性的，已休眠链表中未记录该外挂设备的标识信息时，可将该外挂设备的标识信息写入已唤醒链表。示例性 的，已休眠链表中已记录该外挂设备的标识信息时，可将该外挂设备的标识信息从该已休眠链表中转移至已唤醒链表。此外，电源管理模块可在已唤醒链表中，按照各外挂设备的设备序号来排序外挂设备的位置，以便于基于该已唤醒链表中的各外挂设备的位置，来按照各外挂设备的顺序依赖关系，来进行外设休眠。
在一种可能的实施方式中，在电源管理模块检测到外挂设备未处于运行状态时，可执行S406。
可选地，S406，电源管理模块调用该外挂设备的用于休眠的回调函数。
可选地，S407，电源管理模块检测已唤醒链表中是否包括该外挂设备的标识信息
在S407之后，电源管理模块检测到已唤醒链表中不包括该外挂设备的标识信息，则转至执行S409。
S409，电源管理模块将该外挂设备的标识信息写入已休眠链表。
在S407之后，电源管理模块检测到已唤醒链表中包括该外挂设备的标识信息，则转至执行S408。
S408，电源管理模块将该外挂设备的标识信息从已唤醒链表转移至已休眠链表。
在本实施例中，在***运行时，电源管理模块检测到任意外挂设备未处于运行状态，则可调用外设模块中该外挂设备的用于休眠的回调函数，以休眠该外挂设备。此外，电源管理模块还可将该外挂设备的标识信息记录至已休眠链表。示例性的，已唤醒链表中未记录该外挂设备的标识信息时，可将该外挂设备的标识信息写入已休眠链表。示例性的，已唤醒链表中已记录该外挂设备的标识信息时，可将该外挂设备的标识信息从该已唤醒链表中转移至已休眠链表。此外，电源管理模块可在已休眠链表中，按照各外挂设备的设备序号来排序外挂设备的位置，以便于基于该已休眠链表中的各外挂设备的位置，来按照各外挂设备的顺序依赖关系，来进行外设唤醒。
示例性的，在电源管理模块接收到***休眠请求，并在***休眠流程中，执行到休眠外设的阶段时，如图6b所示，在开始休眠外挂设备时，电源管理模块可遍历已唤醒链表，并基于已唤醒链表中外挂设备之间的依赖顺序(即上述顺序依赖关系)，依次调用外挂设备的用于休眠的回调函数，以将处于运行状态的外挂设备进行关闭，以休眠外设。
可选地，电源管理模块通过调用外挂设备的用于休眠的回调函数，来对外设休眠后，则该外设处于休眠状态，那么可将该外设的设备标识写入已休眠链表，或者将该外设的设备标识从已唤醒链表转移至已休眠链表。从而确保已休眠链表或已唤醒链表记录的数据的完整性。
由于在进入***休眠过程中的休眠外设的步骤之前，部分外设的休眠处理过程已经在***运行时完成。那么在***休眠过程中，在休眠外设时，电源管理模块无需对已休眠的外挂设备进行遍历，并调用该外挂设备的用于休眠的回调函数，而只需要对除已休眠的外挂设备之外的外挂设备(例如处于运行状态的外挂设备)，调用相应的用于休眠的回调函数，可大幅减少对外设的用于休眠的回调函数的调用数量，无需对已休眠的外设再进行休眠操作，从而可提升休眠外设的速度。
在另一种实施方式中，电源管理模块对该运行时休眠唤醒机制的实现过程可与图6a的方案存在部分差异。
在本实施方式中，电源管理模块中可在开机后，初始化生成一个链表3，在主机开机后，电源管理模块可存储与该主机连接的所有外挂设备的标识信息(或者其他可用于标识外挂设备的信息)，并且，在该链表3中，可标记各外挂设备的状态信息(休眠状态或唤醒状态)。示例性的，设备处于休眠状态可为设备未处于运行状态(例如关闭状态)。设备处于唤醒状态可为设备处于运行状态。本实施方式与图6a实施例的主要区别在于本实施例可通过在一个链表中维护所有的外挂设备，并可通过对链表中的外挂设备标记是否处于运行状态的方式，来达到两个链表(例如上述已休眠链表和已唤醒链表)的同样效果，即在***运行时，对外挂设备的休眠或唤醒状态进行记录，以在进入***休眠或唤醒流程时，可对除已休眠的外挂设备之外的外挂设备(例如处于运行状态的外挂设备)进行遍历休眠，来减少待休眠的外挂设备的数量，或，对除已唤醒的外挂设备之外的外挂设备(例如处于关闭状态的外挂设备)进行遍历唤醒，来减少待唤醒的外挂设备的数量，从而缩短休眠外挂设备或唤醒外挂设备的时长。
可选地，在进入***休眠或唤醒过程时，在对外设进行休眠或唤醒后，可将该外设的状态(休眠状态或唤醒状态)更新至该链表3。
此外，由于在休眠或唤醒设备时，对设备有顺序依赖关系要求，因此需要在电源管理模块中还可记录各外挂设备之间的顺序依赖关系，具体实现原理，可与图6a实施例类似，这里不再赘述。
示例性的，电源管理模块可在操作***启动时，在设备初始化时，来生成链表3，包括按照设备序号排序的所有外挂设备的标识。可选地，在设备初始化时，电源管理模块可根据已启动的外挂设备，来将该外挂设备在链表3中的状态标记为唤醒状态，以及将未启动的外挂设备，在链表3中的状态标记为休眠状态。
在***运行时，电源管理模块可检查外挂设备是否处于运行状态。示例性的，电源管理模块可在电源管理模块需要周期性遍历外挂设备时，来执行上述检查步骤。或者，可在电源管理模块需要检测外挂设备的状态时，电源管理模块来执行上述检查步骤。从而避免新增周期性或定时检测外挂设备的运行状态的步骤，以节省信令开销。
在电源管理模块检测到外挂设备的状态为运行状态，或不为运行状态后，可根据对外挂设备的状态的检测结果，来确定是否对链表3中相应的外挂设备的状态进行更新。
例如，设备1(一种外设)在链表3中标记为休眠状态，在***运行时，电源管理模块检测到设备1为运行状态，则电源管理模块可将链表3中设备1的状态从休眠状态更新为唤醒状态(或者运行状态)。可选地，电源管理模块可对该设备1的驱动，调用用于唤醒的回调函数，以唤醒设备1。
再如，设备1在链表3中标记为唤醒状态，在***运行时，电源管理模块检测到设备1为运行状态，则电源管理模块无需对链表3中设备1的状态进行更新。
又如，设备1在链表3中标记为唤醒状态，在***运行时，电源管理模块检测到设备1为关闭状态，则电源管理模块可将链表3中设备1的状态从唤醒状态更新为休眠状态。可选地，电源管理模块可对该设备1的驱动，调用用于休眠的回调函数，以休眠设备1。
那么在本实施方式中，示例性的，在电源管理模块接收到***休眠请求，并在*** 休眠流程中，执行到休眠外设的阶段，在开始休眠外挂设备时，电源管理模块可遍历上述举例的链表3，来确定处于唤醒状态的至少一个外挂设备。并基于至少一个外挂设备各自对应的顺序依赖关系，来依次调用至少一个外挂设备的用于休眠的回调函数，以将处于运行状态的外挂设备进行关闭，以休眠外设。由于在进入***休眠过程中的休眠外设的步骤之前，部分外设的休眠处理过程已经在***运行时完成。那么在***休眠过程中，在休眠外设时，电源管理模块无需对已休眠的外挂设备进行遍历，并调用该外挂设备的用于休眠的回调函数，而只需要对处于运行状态的外挂设备，调用相应的用于休眠的回调函数，可大幅减少对外设的用于休眠的回调函数的调用数量，无需对已休眠的外设再进行休眠操作，从而可提升休眠外设的速度。
继续参照图3a，在S504之后，S505，电源管理模块通过内核处理模块下线从核CPU。
示例性的，S505的实现原理，与上述实施例1中的步骤15类似，这里不再赘述。
本实施例在进行***休眠时，可将从核CPU进行下线操作，在下线从核CPU过程中不进行定时器和任务迁移，并采用stop machine机制最高优先级保证，避免从核CPU下线后，***任务执行不稳定性的问题。
继续参照图3a，在S505之后，S506，内核处理模块休眠核心设备，然后，下线主核CPU。
示例性的，S506的实现原理，与上述实施例1中的步骤16、步骤17类似，这里不再赘述。
在S506之后，中断挂起。
示例性的，此时***的执行阶段进入内核态，外设中断不会被触发。
在S506之后，S507，内核处理模块通知ATF(Arm Trusted Firmware，阿姆安全启动平台)休眠***。
示例性的，在核心设备和主核CPU下线后，内核处理模块可通过psci(power state coordination interface，电源管理接口规范)接口通知ATF***进入休眠状态。
上述流程完成了本申请的***的仪表域的***休眠过程。
关于上述***休眠过程中的相关步骤，与实施例1中的相对应步骤，实现原理类似，因此，在本实施例中，未对相同之处一一赘述，具体细节可参照实施例1、以及图2a、图2b、图2c的相关描述。
图3b为示例性示出的一种***唤醒过程的示意图。
图3b以机动车的CDC为应用场景，本示例中，CDC分为仪表域和娱乐域，其中，仪表域为微内核架构(例如图2a所示的微内核架构)，本申请的***可运行在嵌入式平台。
如图3b所示，该***唤醒过程可包括如下步骤：
S601，电源管理模块接收***唤醒请求并处理。
示例性的，电源管理模块可参照图4a所示的实现过程，通过CPU精准提频机制来实现S601。
示例性的，如图4a所示，电源管理模块对该CPU精准提频机制的实现过程可包括：
S101，电源管理模块接收***唤醒请求。
S102，电源管理模块判断***唤醒请求是否为预设请求。
例如，在机动车CDC的***休眠后，用户按压机动车的启动引擎按钮，则电源管理模块可接收到用户触发的***唤醒请求，以唤醒机动车的操作***。这里的***唤醒请求为与用户体验强相关的预设唤醒请求。
例如，在机动车CDC的***休眠后，***周期性的发送用于唤醒***的心跳指令，以执行相关操作，这里的心跳指令不属于与用户体验强相关的预设唤醒请求，因为，用户并不关心该唤醒过程的速度。且，该唤醒过程对用户是无感知的。
示例性的，***唤醒请求的形式可以是事件，那么电源管理模块可配置表示预设唤醒请求的第二预设事件，那么在触发的***唤醒的事件为第二预设事件时，则可转至执行S103，那么在触发的***唤醒的事件不为第二预设事件时，则可转至执行S104。
S103，电源管理模块在检测到***唤醒请求为预设请求时，可确定对CPU待提频的目标频率为最高工作频率。
示例性的，预设请求可包括预设唤醒请求。
例如，在机动车CDC的***休眠后，用户按压机动车的启动引擎按钮，用户希望机动车***尽快运行，那么电源管理模块可确定待提频的CPU以及该CPU待提频至的目标频率，这里为该CPU的最高工作频率。
示例性的，电源管理模块可配置有各单核CPU或各组CPU(包括多核CPU)的最高工作频率。
S104，电源管理模块在检测到***唤醒请求不是预设请求时，可确定对CPU待提频的目标频率为最佳能效比的工作频率。
例如，在机动车CDC的***休眠后，***周期性的发送用于唤醒***的心跳指令，以执行相关操作，则电源管理模块可接收到图2c所示的中断子***发送的***唤醒请求(这里的心跳指令)，以唤醒机动车***。电源管理模块检测到这里的***唤醒请求不属于与用户体验强相关的预设唤醒请求，可确定待提频的CPU以及将该CPU待提频至的目标频率为该CPU的最佳能效比的工作频率。
示例性的，各CPU的最佳能效比的工作频率是与CPU的硬件强相关的。各CPU的最佳能效比的工作频率，可基于具体的芯片平台的CPU在各工作频率下的功耗测试数据而确定。
继续参照图3b，S601之后，S602，电源管理模块通知内核处理模块唤醒***。
在S602之后，S603，内核处理模块可通知ATF唤醒***。
示例性的，内核处理模块可通过psci接口通知ATF***进入运行状态。
在S603之后，S604，内核处理模块上线主核CPU，然后，唤醒核心设备。
示例性的，S604的实现原理，与上述实施例2中的步骤22、步骤23的实现原理类似，这里不再赘述。
在S604之后，S605，内核处理模块上线从核CPU。
示例性的，S605的实现原理，与上述实施例2中的步骤24的实现原理类似，这里不再赘述。
在S605之后，S606，电源管理模块通过内核处理模块对从核CPU提频。
示例性的，S606的实现原理，与上述实施例2中的步骤25的实现原理类似，这里不再赘述。
在S606之后，S607，电源管理模块通过设备驱动模块唤醒外挂设备。
示例性的，图6a为示例性示出的电源管理模块实现的运行时休眠唤醒机制的实现过程。电源管理模块可结合图6a实现的运行时休眠唤醒机制，来通过图6c所示的唤醒外挂设备的过程，来实现S607。
关于图6a的相关描述，可参照***休眠过程中提及的图6a的相关描述，这里不再赘述。
示例性的，在电源管理模块接收到***唤醒请求，并在***唤醒流程中，执行到唤醒外设的阶段时，如图6c所示，在开始唤醒外挂设备时，电源管理模块可遍历已休眠链表，并基于已休眠链表中外挂设备之间的依赖顺序(即上述顺序依赖关系)，依次调用外挂设备的用于唤醒的回调函数，以将处于关闭状态的外挂设备进行启动运行，以唤醒外设。由于在进入***唤醒过程中的唤醒外设的步骤之前，部分外设的唤醒处理过程已经在***运行时完成。那么在***唤醒过程中，在唤醒外设时，电源管理模块无需对已唤醒的外挂设备进行遍历，并调用该外挂设备的用于唤醒的回调函数，而只需要对已唤醒的外挂设备之外的外挂设备(例如处于关闭状态的外挂设备)，调用相应的用于唤醒的回调函数，可大幅减少对外设的用于唤醒的回调函数的调用数量，无需对已唤醒的外设再进行遍历以进行唤醒操作，从而可提升唤醒外设的速度。
可选地，电源管理模块通过调用外挂设备的用于唤醒的回调函数，来对外设唤醒后，则该外设处于唤醒状态，那么可将该外设的设备标识写入已唤醒链表，或者将该外设的设备标识从已休眠链表转移至已唤醒链表。从而确保已休眠链表或已唤醒链表记录的数据的完整性。
在另一种实施方式中，电源管理模块对该运行时休眠唤醒机制的实现过程可与图6a的方案存在部分差异。
在本实施方式中，电源管理模块中可在开机后，初始化生成一个链表3，关于以链表3举例的实施方式的具体实现细节可参照***休眠过程中的相应描述，这里不再赘述。
那么在本实施方式中，示例性的，在电源管理模块接收到***唤醒请求，并在***唤醒流程中，执行到唤醒外设的阶段，在开始唤醒外挂设备时，电源管理模块可遍历上述举例的链表3，来确定处于休眠状态的至少一个外挂设备。并基于至少一个外挂设备各自对应的顺序依赖关系，来依次调用至少一个外挂设备的用于唤醒的回调函数，以将处于关闭状态的外挂设备进行启动运行，以唤醒外设。由于在进入***唤醒过程中的唤醒外设的步骤之前，部分外设的唤醒处理过程已经在***运行时完成。那么在***唤醒过程中，在唤醒外设时，电源管理模块无需对已唤醒的外挂设备进行遍历，并调用该外挂设备的用于唤醒的回调函数，而只需要对未处于运行状态的外挂设备，调用相应的用于唤醒的回调函数，可大幅减少对外设的用于唤醒的回调函数的调用数量，无需对已唤醒的外设再进行休眠操作，从而可提升唤醒外设的速度。
继续回到图3b，在S607之后，S608，电源管理模块通过内核处理模块解冻普通任务。
示例性的，电源管理模块可向已冻结的普通任务发送解冻信号，那么普通任务接收 到该解冻信号后，可向内核处理模块发送解冻指令，以解冻普通任务，使得冻结后的普通任务可继续运行，以处于运行状态。
可选地，在S608之后，S609，电源管理模块通过内核处理模块解除从核CPU提频。
示例性的，本步骤S609的实现细节与原理，与实施例2中的步骤28类似，这里不再赘述。
上述流程完成了本申请的***的仪表域的***唤醒过程。
关于上述***唤醒过程中的相关步骤，与实施例2中的相对应步骤，实现原理类似，因此，在本实施例中，未对相同之处一一赘述，具体细节可参照实施例2、以及图2a、图2b、图2c的相关描述。
需要说明的是，本申请各实施例中用于存储数据的数据结构并不限于上述各实施例举例的链表，还可以包括但不限于：数组、向量、XML文件、变量、键值对、队列、栈、树、堆、散列表等。
需要说明的是，本申请各个实施例中提及的，对某个对象“上线”可用于表示对该对象上电，例如上线CPU表示对CPU上电。对某个对象“下线”可用于表示对该对象下电，例如下电CPU表示对CPU下电。对设备的休眠可用于表示关闭该设备或对该设备下电，以使该设备停止运行。对设备的唤醒可用于表示启动该设备或对该设备上电，以使该设备运行。
在一种可能的实施方式中，本申请提供一种***休眠装置。该***休眠装置包括：过滤模块，用于响应于接收到***休眠请求，过滤处于阻塞状态的第一任务；冻结模块，用于对过滤后的未处于阻塞状态的第二任务进行冻结；休眠设备模块，用于基于设备状态信息，对第一类型的第一设备进行休眠；其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中未处于运行状态的设备。
在一种可能的实施方式中，所述***休眠装置还包括：第一提频模块，用于在检测到所述***休眠请求为预设休眠请求时，将CPU的工作频率提高至第一频率；其中，所述第一频率为所述CPU的最高工作频率。
在一种可能的实施方式中，所述***休眠装置还包括：第二提频模块，用于在检测到所述***休眠请求不为预设休眠请求时，将所述CPU的工作频率提高至第二频率；其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
在一种可能的实施方式中，所述过滤模块，具体用于在第二类型的任务中，过滤处于阻塞状态的第一任务；其中，所述第二类型的任务为操作***中除***任务之外的任务。
在一种可能的实施方式中，所述***休眠装置还包括：发送信号模块，用于对所述第二类型的任务发送冻结信号，所述冻结信号用于指示任务进行冻结。
在一种可能的实施方式中，所述***休眠装置还包括：保存模块，用于将所述第二 任务中未处于冻结状态的第三任务，保存至第一数据结构；遍历模块，用于对第一数据结构中的所述第三任务进行循环遍历，并对遍历的所述第三任务检测任务状态；删除模块，用于在所述第一数据结构中检测到第三任务的任务状态为所述冻结状态时，将处于冻结状态的该第三任务从所述第一数据结构删除；所述遍历模块，还用于在所述第一数据结构中检测到第三任务的任务状态不为所述冻结状态时，继续循环遍历所述第一数据结构，直至所述第一数据结构为空。
在一种可能的实施方式中，所述***的CPU为多核CPU，所述多核CPU包括主核CPU和至少一个从核CPU，所述***休眠装置还包括：保留模块，用于在对第一从核CPU下电之前，将所述第一从核CPU上的定时器及任务进行保留而不迁移至第二CPU；其中，所述第二CPU为第二从核CPU或所述主核CPU；所述至少一个从核CPU包括所述第一从核CPU，或者，进一步包括所述第二从核CPU。
在一种可能的实施方式中，所述休眠设备模块，具体用于：基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；对所述第一设备进行休眠。
在一种可能的实施方式中，所述***休眠装置还包括：设备状态管理模块，用于：在所述***运行过程中，检测到所述第一类型的第三设备处于运行状态时，将所述第三设备的设备状态，记录或更新为第一状态，以生成或更新所述设备状态信息；其中，所述第一状态为用于表示所述第三设备处于运行状态的信息；在所述***运行过程中，检测到所述第一类型的第四设备未处于运行状态时，将所述第四设备的设备状态，记录或更新为第二状态，以生成或更新所述设备状态信息；其中，所述第二状态为用于表示所述第四设备未处于运行状态的信息；所述设备状态为所述第一状态或所述第二状态；其中，所述至少一个设备包括：所述第三设备和/或所述第四设备。
在一种可能的实施方式中，所述设备状态管理模块，还用于在所述设备状态信息中，记录或更新所述第一设备的设备状态为所述第二状态。
上述各实施方式的***休眠装置的效果，与上述各实施方式的***休眠方法的效果类似，这里不再赘述。
在一种可能的实施方式中，本申请提供一种***唤醒装置。该***唤醒装置包括：唤醒设备模块，用于响应于接收到***唤醒请求，基于设备状态信息，对第一类型的第一设备进行唤醒；其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中处于运行状态的设备；解冻模块，用于对处于冻结状态的第一任务进行解冻；其中，所述第一任务在冻结时未处于阻塞状态。
在一种可能的实施方式中，所述***唤醒装置还包括：第一提频模块，用于在CPU上线之后，在检测到所述***唤醒请求为预设唤醒请求时，将CPU的工作频率提高至第一频率；其中，所述第一频率为所述CPU的最高工作频率。
在一种可能的实施方式中，所述***唤醒装置还包括：第二提频模块，用于在CPU 上线之后，在检测到所述***唤醒请求不为预设唤醒请求时，将所述CPU的工作频率提高至第二频率；其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
在一种可能的实施方式中，所述***唤醒装置还包括：解除提频模块，用于将所述CPU的调频策略，恢复为原调频策略；其中，所述原调频策略为在接收到所述***唤醒请求之前，所述CPU的调频策略。
在一种可能的实施方式中，所述第一任务为在第二类型的任务中，未处于阻塞状态的任务，其中，所述第二类型的任务为操作***中除***任务之外的任务。
在一种可能的实施方式中，所述唤醒设备模块，具体用于：基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；对所述第一设备进行唤醒。
在一种可能的实施方式中，所述***唤醒装置还包括：设备状态管理模块，用于：在所述***运行过程中，检测到所述第一类型的第三设备处于运行状态时，将所述第三设备的设备状态，记录或更新为第一状态，以生成或更新所述设备状态信息；其中，所述第一状态为用于表示所述第三设备处于运行状态的信息；在所述***运行过程中，检测到所述第一类型的第四设备未处于运行状态时，将所述第四设备的设备状态，记录或更新为第二状态，以生成或更新所述设备状态信息；其中，所述第二状态为用于表示所述第四设备未处于运行状态的信息；所述设备状态为所述第一状态或所述第二状态；其中，所述至少一个设备包括：所述第三设备和/或所述第四设备。
在一种可能的实施方式中，所述设备状态管理模块，还用于在所述设备状态信息中，记录或更新所述第一设备的设备状态为所述第一状态。
上述各实施方式的***唤醒装置的效果，与上述各实施方式的***唤醒方法的效果类似，这里不再赘述。
在一种可能的实施方式中，图7a为本申请实施例提供的一种***休眠装置的结构示意图。如图7a所示，该***休眠装置500可包括：处理器501、收发器505，可选的还包括存储器502。
所述收发器505可以称为收发单元、收发机、或收发电路等，用于实现收发功能。收发器505可以包括接收器和发送器，接收器可以称为接收机或接收电路等，用于实现接收功能；发送器可以称为发送机或发送电路等，用于实现发送功能。
存储器502中可存储计算机程序或软件代码或指令504，该计算机程序或软件代码或指令504还可称为固件。处理器501可通过运行其中的计算机程序或软件代码或指令503，或通过调用存储器502中存储的计算机程序或软件代码或指令504，对MAC层和PHY层进行控制，以实现本申请各实施例提供的***休眠方法。其中，处理器501可以为中央处理器(central processing unit，CPU)，存储器502例如可以为只读存储器(read-only memory，ROM)，或为随机存取存储器(random access memory，RAM)。
本申请中描述的处理器501和收发器505可实现在集成电路(integrated circuit，IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(application specific  integrated circuit，ASIC)、印刷电路板(printed circuit board，PCB)、电子设备等上。
上述***休眠装置500还可以包括天线506，该***休眠装置500所包括的各模块仅为示例说明，本申请不对此进行限制。
在另一种可能的实施方式中，图7b为本申请实施例提供的一种***唤醒装置的结构示意图。如图7b所示，该***唤醒装置500可包括：处理器501、收发器505，可选的还包括存储器502。
所述收发器505可以称为收发单元、收发机、或收发电路等，用于实现收发功能。收发器505可以包括接收器和发送器，接收器可以称为接收机或接收电路等，用于实现接收功能；发送器可以称为发送机或发送电路等，用于实现发送功能。
存储器502中可存储计算机程序或软件代码或指令504，该计算机程序或软件代码或指令504还可称为固件。处理器501可通过运行其中的计算机程序或软件代码或指令503，或通过调用存储器502中存储的计算机程序或软件代码或指令504，对MAC层和PHY层进行控制，以实现本申请各实施例提供的***唤醒方法。其中，处理器501可以为中央处理器(central processing unit，CPU)，存储器502例如可以为只读存储器(read-only memory，ROM)，或为随机存取存储器(random access memory，RAM)。
本申请中描述的处理器501和收发器505可实现在集成电路(integrated circuit，IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(application specific integrated circuit，ASIC)、印刷电路板(printed circuit board，PCB)、电子设备等上。
上述***唤醒装置500还可以包括天线506，该***唤醒装置500所包括的各模块仅为示例说明，本申请不对此进行限制。
***休眠装置的结构可以不受图7a的限制。***唤醒装置的结构可以不受图7b的限制。***休眠装置、***唤醒装置可以是独立的设备或者可以是较大设备的一部分。例如所述***休眠装置，或***唤醒装置的实现形式可以是：
(1)独立的集成电路IC，或芯片，或，芯片***或子***；(2)具有一个或多个IC的集合，可选的，该IC集合也可以包括用于存储数据，指令的存储部件；(3)可嵌入在其他设备内的模块；(4)车载设备等等；(5)其他等等。
对于***休眠装置，或***唤醒装置的实现形式是芯片或芯片***的情况，可参见图8所示的芯片的结构示意图。图8所示的芯片包括处理器601和接口602。其中，处理器601的数量可以是一个或多个，接口602的数量可以是多个。可选的，该芯片或芯片***可以包括存储器603。
其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
基于相同的技术构思，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序包含至少一段代码，该至少一段代码可由 计算机执行，以控制计算机用以实现上述***休眠方法或***唤醒方法实施例。
基于相同的技术构思，本申请实施例还提供一种计算机程序，当该计算机程序被终端设备执行时，用以实现上述***休眠方法或***唤醒方法实施例。
所述程序可以全部或者部分存储在与处理器封装在一起的存储介质上，也可以部分或者全部存储在不与处理器封装在一起的存储器上。
基于相同的技术构思，本申请实施例还提供一种芯片，包括网口控制器与处理器。网口控制器与处理器可实现上述***休眠方法或***唤醒方法实施例。
结合本申请实施例公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(Random Access Memory，RAM)、闪存、只读存储器(Read Only Memory，ROM)、可擦除可编程只读存储器(Erasable Programmable ROM，EPROM)、电可擦可编程只读存储器(Electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (23)

  1. 一种***休眠方法，其特征在于，所述方法包括：
    响应于接收到***休眠请求，过滤处于阻塞状态的第一任务；
    对过滤后的未处于阻塞状态的第二任务进行冻结；
    基于设备状态信息，对第一类型的第一设备进行休眠；
    其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；
    所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中未处于运行状态的设备。
  2. 根据权利要求1所述的方法，其特征在于，所述过滤处于阻塞状态的第一任务之前，所述方法还包括：
    在检测到所述***休眠请求为预设休眠请求时，将CPU的工作频率提高至第一频率；
    其中，所述第一频率为所述CPU的最高工作频率。
  3. 根据权利要求1或2所述的方法，其特征在于，所述过滤处于阻塞状态的第一任务之前，所述方法还包括：
    在检测到所述***休眠请求不为预设休眠请求时，将所述CPU的工作频率提高至第二频率；
    其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
  4. 根据权利要求1至3中任意一项所述的方法，其特征在于，所述过滤处于阻塞状态的第一任务，包括：
    在第二类型的任务中，过滤处于阻塞状态的第一任务；
    其中，所述第二类型的任务为操作***中除***任务之外的任务。
  5. 根据权利要求1至4中任意一项所述的方法，其特征在于，所述过滤处于阻塞状态的第一任务之后，所述基于设备状态信息，对第一类型的第一设备进行休眠之前，所述方法还包括：
    将所述第二任务中未处于冻结状态的第三任务，保存至第一数据结构；
    对第一数据结构中的所述第三任务进行循环遍历，并对遍历的所述第三任务检测任务状态；
    在所述第一数据结构中检测到第三任务的任务状态为所述冻结状态时，将处于冻结状态的该第三任务从所述第一数据结构删除；
    在所述第一数据结构中检测到第三任务的任务状态不为所述冻结状态时，继续循环遍历所述第一数据结构，直至所述第一数据结构为空。
  6. 根据权利要求1至5中任意一项所述的方法，其特征在于，所述基于设备状态信息，对第一类型的第一设备进行休眠，包括：
    基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；
    对所述第一设备进行休眠。
  7. 一种***唤醒方法，其特征在于，所述方法包括：
    响应于接收到***唤醒请求，基于设备状态信息，对第一类型的第一设备进行唤醒；
    其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；
    所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中处于运行状态的设备；
    对处于冻结状态的第一任务进行解冻；
    其中，所述第一任务在冻结时未处于阻塞状态。
  8. 根据权利要求7所述的方法，其特征在于，所述基于设备状态信息，对第一类型的第一设备进行唤醒之前，所述方法还包括：
    在CPU上线之后，在检测到所述***唤醒请求为预设唤醒请求时，将所述CPU的工作频率提高至第一频率；
    其中，所述第一频率为所述CPU的最高工作频率。
  9. 根据权利要求7或8所述的方法，其特征在于，所述基于设备状态信息，对第一类型的第一设备进行唤醒之前，所述方法还包括：
    在所述CPU上线之后，在检测到所述***唤醒请求不为预设唤醒请求时，将所述CPU的工作频率提高至第二频率；
    其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
  10. 根据权利要求7至9中任意一项所述的方法，其特征在于，
    所述第一任务为在第二类型的任务中，未处于阻塞状态的任务，其中，所述第二类型的任务为操作***中除***任务之外的任务。
  11. 根据权利要求7至10中任意一项所述的方法，其特征在于，所述基于设备状态信息，对第一类型的第一设备进行唤醒，包括：
    基于所述基于设备状态信息，在第一类型的设备中过滤所述第二设备，以确定所述第一类型的第一设备；
    对所述第一设备进行唤醒。
  12. 一种***休眠装置，其特征在于，
    过滤模块，用于响应于接收到***休眠请求，过滤处于阻塞状态的第一任务；
    冻结模块，用于对过滤后的未处于阻塞状态的第二任务进行冻结；
    休眠设备模块，用于基于设备状态信息，对第一类型的第一设备进行休眠；
    其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；
    所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中未处于运行状态的设备。
  13. 根据权利要求12所述的装置，其特征在于，所述装置还包括：
    第一提频模块，用于在检测到所述***休眠请求为预设休眠请求时，将CPU的工作频率提高至第一频率；
    其中，所述第一频率为所述CPU的最高工作频率。
  14. 根据权利要求12或13所述的装置，其特征在于，所述装置还包括：
    第二提频模块，用于在检测到所述***休眠请求不为预设休眠请求时，将所述CPU的工作频率提高至第二频率；
    其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
  15. 根据权利要求12至14中任意一项所述的装置，其特征在于，
    所述过滤模块，具体用于在第二类型的任务中，过滤处于阻塞状态的第一任务；
    其中，所述第二类型的任务为操作***中除***任务之外的任务。
  16. 一种***唤醒装置，其特征在于，所述装置包括：
    唤醒设备模块，用于响应于接收到***唤醒请求，基于设备状态信息，对第一类型的第一设备进行唤醒；
    其中，所述设备状态信息包括：第一类型的至少一个设备的设备状态，所述设备状态为用于表示设备是否处于运行状态的信息；
    所述第一设备与第二设备不同，其中，所述第二设备为所述至少一个设备中处于运行状态的设备；
    解冻模块，用于对处于冻结状态的第一任务进行解冻；
    其中，所述第一任务在冻结时未处于阻塞状态。
  17. 根据权利要求16所述的装置，其特征在于，所述装置还包括：
    第一提频模块，用于在CPU上线之后，在检测到所述***唤醒请求为预设唤醒请求时，将CPU的工作频率提高至第一频率；
    其中，所述第一频率为所述CPU的最高工作频率。
  18. 根据权利要求16或17所述的装置，其特征在于，所述装置还包括：
    第二提频模块，用于在CPU上线之后，在检测到所述***唤醒请求不为预设唤醒请求时，将所述CPU的工作频率提高至第二频率；
    其中，所述第二频率小于所述第一频率，其中，在所述CPU的工作频率为所述第二频率时，所述CPU的能效比最高。
  19. 根据权利要求16至18中任意一项所述的装置，其特征在于，
    所述第一任务为在第二类型的任务中，未处于阻塞状态的任务，其中，所述第二类型的任务为操作***中除***任务之外的任务。
  20. 一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序运行在计算机或处理器上时，使得所述计算机或所述处理器执行如权利要求1至6，或权利要求7至11中任意一项所述的方法。
  21. 一种***休眠装置，其特征在于，包括一个或多个接口电路和一个或多个处理器；所述接口电路用于从存储器接收信号，并向所述处理器发送所述信号，所述信号包括存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，所述处理器用于执行如权利要求1至6中任意一项所述的方法。
  22. 一种***唤醒装置，其特征在于，包括一个或多个接口电路和一个或多个处理器；所述接口电路用于从存储器接收信号，并向所述处理器发送所述信号，所述信号包括存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，所述处理器用于执行如权利要求7至11中任意一项所述的方法。
  23. 一种计算机程序产品，其特征在于，所述计算机程序产品包括软件程序，当所述软件程序被计算机或处理器执行时，使得权利要求1至6，或权利要求7至11任一项所述的方法的步骤被执行。
PCT/CN2022/095695 2022-04-29 2022-05-27 ***休眠方法及装置、***唤醒方法及装置 WO2023206693A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210466672.6A CN117008980A (zh) 2022-04-29 2022-04-29 ***休眠方法及装置、***唤醒方法及装置
CN202210466672.6 2022-04-29

Publications (1)

Publication Number Publication Date
WO2023206693A1 true WO2023206693A1 (zh) 2023-11-02

Family

ID=88517101

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/095695 WO2023206693A1 (zh) 2022-04-29 2022-05-27 ***休眠方法及装置、***唤醒方法及装置

Country Status (2)

Country Link
CN (1) CN117008980A (zh)
WO (1) WO2023206693A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102621912A (zh) * 2011-01-27 2012-08-01 赛酷特(北京)信息技术有限公司 单片机自动节电方法
CN105101371A (zh) * 2015-08-10 2015-11-25 上海闻泰电子科技有限公司 一种手机省电管理方法
CN106658365A (zh) * 2016-11-18 2017-05-10 青岛海信移动通信技术股份有限公司 一种基于低功耗蓝牙协议的通信方法和装置
US20170300103A1 (en) * 2014-09-19 2017-10-19 Huawei Technologies Co., Ltd. Method and apparatus for running application program
CN108304223A (zh) * 2017-12-22 2018-07-20 天津麒麟信息技术有限公司 一种用于电源休眠机制的操作***与硬件平台交互方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8271812B2 (en) * 2010-04-07 2012-09-18 Apple Inc. Hardware automatic performance state transitions in system on processor sleep and wake events
CN102866934B (zh) * 2011-07-05 2015-10-28 中国科学院上海微***与信息技术研究所 基于非易失随机存储器的嵌入式设备的休眠及唤醒***
CN105373207B (zh) * 2014-08-20 2018-10-12 深圳飞音时代网络通讯技术有限公司 一种无线通信终端的待机方法
CN111506351A (zh) * 2020-04-03 2020-08-07 珠海市一微半导体有限公司 片上***的深度休眠方法、唤醒方法和休眠与唤醒方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102621912A (zh) * 2011-01-27 2012-08-01 赛酷特(北京)信息技术有限公司 单片机自动节电方法
US20170300103A1 (en) * 2014-09-19 2017-10-19 Huawei Technologies Co., Ltd. Method and apparatus for running application program
CN105101371A (zh) * 2015-08-10 2015-11-25 上海闻泰电子科技有限公司 一种手机省电管理方法
CN106658365A (zh) * 2016-11-18 2017-05-10 青岛海信移动通信技术股份有限公司 一种基于低功耗蓝牙协议的通信方法和装置
CN108304223A (zh) * 2017-12-22 2018-07-20 天津麒麟信息技术有限公司 一种用于电源休眠机制的操作***与硬件平台交互方法

Also Published As

Publication number Publication date
CN117008980A (zh) 2023-11-07

Similar Documents

Publication Publication Date Title
US10387191B2 (en) Task processor
US6981163B2 (en) Method and apparatus for power mode transition in a multi-thread processor
EP1677175B1 (en) Dynamic power management in system on chips (SOC)
US7577856B2 (en) Unified device power management engine
KR102048329B1 (ko) 애플리케이션 프로그램 실행 방법 및 장치
JP2015064676A (ja) 情報処理装置、半導体装置、情報処理方法およびプログラム
US20100287360A1 (en) Task Processing Device
US8327379B2 (en) Method for switching a selected task to be executed according with an output from task selecting circuit
GB2402519A (en) Power management in a multiprocessor system
JP2014501982A (ja) 電力管理のためのシステム及び方法
CN107533353B (zh) 控制设备在正常状态与静止状态之间的转换
KR20140127341A (ko) 휴대용 컴퓨팅 디바이스에서 요청들을 스케쥴링하기 위한 방법 및 시스템
US8452995B1 (en) Universal serial bus low power idle mode
CN112711476A (zh) 一种计算机运行状态管理方法、计算设备及存储介质
US7308586B2 (en) Interlocked plug and play with power management for operating systems
US7565558B2 (en) Power saving method and system for a central processing unit disposed in a non-snooping sleep state when a peripheral device sends a bus master request
WO2023206693A1 (zh) ***休眠方法及装置、***唤醒方法及装置
CN115729312A (zh) 自动切换处理器时钟的控制***及芯片
KR101285665B1 (ko) 수면 모드를 지원하는 멀티 코어 시스템 온 칩
WO2017102038A1 (en) Method and arrangement for utilization of a processing arrangement
JP2010049700A (ja) タスク処理装置
US20160216756A1 (en) Power management in computing devices
Vaddagir et al. Power management
JPH02120938A (ja) データ処理方法

Legal Events

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

Ref document number: 22939526

Country of ref document: EP

Kind code of ref document: A1