Patent ID: 12242325

DETAILED DESCRIPTION

Overview

In many cases, it is beneficial to deactivate certain cores of a multi-core processor, such as by removing slower cores, removing higher power cores, removing hot cores, and so forth. However, conventional systems require a reboot of the system in order to re-initialize the desired cores and to reset the operating system's awareness of available cores. Rebooting the system, however, is obtrusive to the end user experience while also disrupting active workloads and subjecting the system and end user to the time and stress of a reboot cycle.

To solve these problems, the described techniques enable selective activation and deactivation of cores of a processor “on the fly” and without rebooting the system. Moreover, the system adjusts the active cores of the processor and also informs the operating system of the cores which are currently active, which enables the operating system to inform various applications of the cores which are currently active. Doing so prevents applications and the operating system from scheduling tasks on deactivated cores and instead causes the system to utilize only the activated cores for performing tasks.

The ability to dynamically change the number of active cores without rebooting the system reduces the disruption to active workloads while also improving the end user experience as compared to conventional systems. Moreover, activating and deactivating cores “on the fly” enables the system to optimize the number of active cores for a variety of different usage scenarios and system conditions, such as by deactivating cores that are too hot or too slow, optimizing the number of active cores for different applications or workflows, and so forth.

In some aspects, the techniques described herein relate to a method including: operating a processor having multiple cores using a first core configuration, receiving a request to switch from the first core configuration to a second core configuration, and responsive to the request, switching from the first core configuration to the second core configuration by adjusting a number of active cores of the processor without rebooting.

In some aspects, the techniques described herein relate to a method, wherein the switching from the first core configuration to the second core configuration further includes deactivating one or more cores of the processor without rebooting.

In some aspects, the techniques described herein relate to a method, wherein the switching from the first core configuration to the second core configuration further includes activating one or more cores of the processor without rebooting.

In some aspects, the techniques described herein relate to a method, wherein the first core configuration has a different number of active cores than the second core configuration.

In some aspects, the techniques described herein relate to a method, wherein the first core configuration has a different selection of active cores than the second core configuration.

In some aspects, the techniques described herein relate to a method, further including informing an operating system of the number of active cores.

In some aspects, the techniques described herein relate to a method, wherein the informing includes providing an active core report to the operating system, wherein the active core report is formatted according to an Advanced Configuration and Power Interface (ACPI) specification.

In some aspects, the techniques described herein relate to a method, wherein the informing causes the operating system to provide an indication of the active cores to one or more applications.

In some aspects, the techniques described herein relate to a method, further including informing at least one of an operating system or applications about a branding configuration of the processor corresponding to the second core configuration.

In some aspects, the techniques described herein relate to a method, wherein the request is received via user input to a user interface that selects one or more cores to deactivate.

In some aspects, the techniques described herein relate to a method, wherein the request is received via user input to a user interface that selects one or more cores to activate.

In some aspects, the techniques described herein relate to a method, wherein the request is received from an application or an operating system.

In some aspects, the techniques described herein relate to a system including: a memory, a processor having multiple cores, and a controller configured to selectively activate and deactivate cores of the processor without rebooting.

In some aspects, the techniques described herein relate to a system, wherein the controller is configured to deactivate cores of the processor without rebooting by communicating signals to the processor for power gating or clock gating cores that are to be deactivated.

In some aspects, the techniques described herein relate to a system, wherein the controller is configured to selectively activate and deactivate cores of the processor without rebooting by switching from a first core configuration to a second core configuration.

In some aspects, the techniques described herein relate to a system, wherein the first core configuration has a different number of active cores than the second core configuration.

In some aspects, the techniques described herein relate to a system, wherein the first core configuration has a different selection of active cores than the second core configuration.

In some aspects, the techniques described herein relate to a system, wherein the controller is further configured to inform an operating system of a number and selection of active cores of the processor.

In some aspects, the techniques described herein relate to a method including: displaying a user interface including controls for activating or deactivating cores of a processor having multiple cores, receiving, via the user interface, user input to deactivate one or more cores of the processor, and deactivating the one or more cores of the processor without rebooting.

In some aspects, the techniques described herein relate to a method, wherein the user interface includes controls for activating or deactivating each of the multiple cores of the processor.

FIG.1is a block diagram of a non-limiting example system100having a processor with multiple cores and a controller that activates and deactivates the cores without rebooting. In particular, the system100includes processor102which has multiple cores104. Processors having multiple cores (e.g., two or more separate processing units) on a single integrated circuit are commonly referred to as “multi-core processors.” The system100also includes controller106and memory108. The processor102, the controller106, and the memory108are operable to implement operating system110and one or more applications112.

In accordance with the described techniques, the processor102, the controller106, and the memory108are coupled to one another via a wired or wireless connection. Example wired connections include, but are not limited to, system buses connecting two or more of the processor102, the controller106, and the memory108. Examples of devices in which the system100is implemented include, but are not limited to, servers, personal computers, laptops, desktops, game consoles, set top boxes, tablets, smartphones, mobile devices, virtual and/or augmented reality devices, wearables, medical devices, systems on chips, and other computing devices or systems.

The memory108is a device or system that is used to store information, such as for immediate use in a device, e.g., by the processor102. In one or more implementations, the memory108corresponds to semiconductor memory where data is stored within memory cells on one or more integrated circuits. In at least one example, the memory108corresponds to or includes volatile memory, examples of which include random-access memory (RAM), dynamic random-access memory (DRAM), synchronous dynamic random-access memory (SDRAM), and static random-access memory (SRAM). Alternatively or in addition, the memory108corresponds to or includes non-volatile memory, examples of which include flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electronically erasable programmable read-only memory (EEPROM). The memory108is configurable in a variety of ways that support dynamically adjusting a number and selection of active cores in the processor102without departing from the spirit or scope of the described techniques.

Broadly, the controller106communicates with the operating system110to adjust operation of hardware components, including operation of the processor102. By way of example, and not limitation, the controller106sends signals to those components (e.g., the processor102) to adjust their operation, such as by sending signals to adjust power consumption of the components, to adjust a speed of a cooling fan, and to activate and/or deactivate components. This includes sending signals to adjust operation of components to prevent overheating and use of excess energy. In one or more variations, the controller106is implemented using hardware, software, firmware or a combination thereof. One example of the controller106is a system management unit (SMU) which has SMU firmware.

In accordance with the described techniques, the controller106is configured to selectively activate and deactivate the cores104of the processor102without rebooting the system100. For instance, the controller106is configured to signal the processor102to activate or deactivate the cores104on an individual basis without rebooting the system100. Alternatively or in addition, the controller106is configured to signal the processor102to activate or deactivate multiple cores104at a time without rebooting the system100. In one or more implementations, the controller106communicates signals to the processor102for power gating and/or clock gating the cores104that are to be deactivated. Such signals, communicated by the controller106to the processor102to adjust a number of active cores104and/or adjust which of the cores104are activated or deactivated, are illustrated as core adjustment signals114.

Adjusting which cores of a multi-core processor are active “on the fly” (e.g., without rebooting) contrasts with conventional techniques. For instance, conventional approaches involve rebooting the system. During this reboot, an adjusted number or selection of cores is activated. Further, the operating system is informed about the number or selection of active cores as part of the reboot. In accordance with the described techniques, though, the controller106adjusts the number or selection of active cores104without rebooting and also informs the operating system of the cores which are currently active.

In the illustrated example, the controller106is depicted receiving a request116from the operating system110. The controller106is also depicted as informing the operating system110of the number of active cores. In this example, the controller106informs the operating system110of the number of active cores by providing an active core report118to the operating system110. Broadly, the request116indicates an adjustment to a number or selection of the cores104of the processor102, such that how many cores104and/or which cores104to activate or deactivate is indicated in or determinable from the request116. The active core report118indicates to the operating system110an adjustment to the active cores104, e.g., the active core report118indicates which of the cores104are activated (or deactivated) in connection with the adjustment. In this way, the controller106informs the operating system110and the applications112of the current core count, e.g., the number of cores104that are active. In one or more implementations, the active core report118includes a brand string, which identifies a branding configuration of the processor102. In this way, the controller106informs the operating system110and the applications112about the branding configuration of the processor102, in at least one implementation. Through the active core report118, the operating system110is thus made “aware” of the adjustment carried out by the controller106, which it carries out by power gating and/or clock gating one or more of the cores104.

In one or more implementations, in order to inform the operating system110about which cores104are activated (or deactivated) in connection with an adjustment, the controller106formats the active core report118. For instance, the controller106formats the active core report118according to a specification associated with a power configuration. In one or more implementations, the controller106formats the active core report118according to the Advanced Configuration and Power Interface (ACPI) specification. In at least one such implementation, the controller106is configured to indicate (e.g., falsely) to the operating system110via the active core report118that selective cores104(e.g., which are requested to be deactivated) are too hot (e.g., hotter than a threshold) or are not available, even though a physical temperature of those cores104does not actually exceed the threshold. When the operating system110is notified that a core104is too hot, the operating system110is configured to programmatically take the core104“offline” so that it is not available for use. Due to this, a scheduler (not shown) of the operating system110avoids scheduling threads, processes, and/or data flows using the cores104that have been taken offline.

In at least one example implementation, the operating system110and/or one or more of its components, are configured to monitor thermal zones (e.g., of the processor102) and, based on the monitoring, they are further configured to instruct the controller106(e.g., via the request116) to control conditions (e.g., power consumption and cooling-fan speed) under which hardware components in those thermal zones operate. In this example, the operating system110and/or those one or more components are not configured to monitor the cores104, per se, or to instruct the controller106, specifically, to activate or deactivate particular cores104. This can be the case where the communications between the operating system110and the controller106are governed by a specification, such as the ACPI specification. At least one version of the ACPI specification specifies communication protocols for controlling operating conditions of hardware components on a thermal-zone by thermal-zone basis—rather than on a core-by-core basis. In at least one such implementation, the described techniques therefore exploit these communication protocols to activate and deactivate the cores104without rebooting the system and also so that the operating system110is aware of the active cores104.

By way of example, in one or more implementations where communication between the operating system110and the controller106is governed at least in part by such a specification, the controller106includes a table (not shown) that maps thermal zones to the cores104. For instance, the table maps each core104to a respective thermal zone, such that there is a one-to-one mapping between the cores104and thermal zones. Accordingly, when the controller106receives an indication (via the request116) that a thermal zone is “too hot,” the controller106identifies the respective core104, based on the mapping between thermal zones and cores104in the table, and then deactivates the respective core104.

In implementations that further involve outputting a user interface and allowing a user to select which cores104of the processor102to activate or deactivate via the user interface, an application112or firmware that corresponds to the user interface also maps selected cores104to thermal zones, e.g., by using a table similar to the one included at the controller106. Based on the mapping, the application112or firmware is configured to communicate an indication to the operating system110which specifies thermal zones to control. This is so that the operating system110receives a type of information that enables it to communicate with the controller106, e.g., thermal-zone based information rather than core-based information.

Although the example discussed just above exploits a protocol for configuring communications between the operating system110and the controller106(e.g., the request116and the active core report118) based on thermal zones, in one or more implementations, the communications between the operating system110and the controller106are configured based on cores. In such implementations, use of a mapping between cores and thermal zones (e.g., maintained in one or more tables) is not necessary. The request116and the active core report118are configurable in various ways—that enable the controller106to activate and deactivate the cores104on a core-by-core basis “on the fly” and that enable the operating system110to inform applications112how many cores are “online” and also when cores104go “offline” without rebooting—without departing from the spirit or scope of the described techniques.

Once informed about an adjusted configuration of active cores104, the operating system110further provides an indication of the active cores104to the applications112. In the illustrated example, core indication120indicates to the applications112the number of active cores104of the processor102that are operable. Based on the number of active cores104, a scheduler of the operating system110schedules tasks122for processing by the processor102's cores104, e.g., on the active cores104. These tasks122include threads, processes, and data flows for implementing the applications112and the operating system110.

In one or more implementations, the system100enables users to provide input for adjusting the active cores104, such as a number of active cores and/or which specific cores104are activated and deactivated. Example user interfaces which enable users to request adjustments to the active cores are discussed in more detail in relation toFIGS.3-5. In such examples, the request116is based on and responsive to user input.

Alternatively or in addition, the system100enables one or more of the applications112to request adjustments to the active cores, such as a number of active cores and/or which specific cores104are activated and deactivated. In such examples, the request116is based on and responsive to communication from an application112. Alternatively or in addition, the operating system110(or a process of the operating system110) is configured to request adjustments to the activated cores for various applications112. For instance, when a particular application112associated with a particular core configuration is launched, the system100enables the operating system110, or a process that controls core configurations for various applications, to request an adjustment of the processor102's core configuration to the particular core configuration associated with the particular application.

In one or more implementations, a number of cores104and/or which of the cores104are activated and deactivated is based on thermal optimization and/or power optimization. Where active cores104are adjusted based on thermal optimization, for instance, the number and selection of cores104for at least one configuration is adjusted so that each activated core104is spaced sufficiently on the processor102's integrated circuit from other activated cores. In other words, there is sufficient space on the integrated circuit between a physical position of each active core104.

Consider an example in which the processor102includes eight cores and in which those eight cores104are arranged substantially along an axis, e.g., they are arranged “in a line.” In this example, consider also that three of the eight cores104are to be activated. In order to minimize a thermal impact of the cores104on one another, one example core configuration corresponds to having the first core104, the eighth core104, and either the third or fourth core104activated and the other cores104deactivated.

In one or more implementations, at least one of the controller106, the operating system110, or an application112is configured to determine (or specify) which of the cores104to activate based on a number of cores104to be activated and based on optimizing for thermal conditions. By way of example, the controller106, the operating system110, or the application112references a table that specifies which cores104of the processor102to activate based on a number of active cores104and a type of optimization, e.g., thermal. Alternatively or in addition, the controller106, the operating system110, and/or the application112requests to switch from using cores104that are activated at a given time to instead using the cores104that are deactivated at the given time (and are potentially cooled down relative to the activated cores), e.g., by activating one or more of those deactivated cores.

In at least one implementation where active cores104are adjusted based on power optimization, the number and selection of cores104for at least one configuration is adjusted so that an amount of power consumed by the cores104in connection with performing the tasks122(e.g., threads, processes, and data flows) is minimized. Consider an example in which an application112requires only one of the processor102's multiple cores104to perform the application112's tasks optimally. In this example, and without consideration of tasks122associated with other applications112or the operating system110, an example core configuration corresponds to having only one of the cores104activated and the other cores104deactivated.

In one or more implementations, at least one of the controller106, the operating system110, or an application112is configured to determine (or specify) which of the cores to activate based on optimizing for power consumption. By way of example, the controller106and/or the operating system110is configured to determine a number and selection of cores104to activate based on specified core requirements of active applications112, the tasks122of those applications, and/or the tasks122of the operating system110. In other words, core requirements of multiple applications112and the operating system110are taken into account when determining a number and selection of cores104to activate in order to optimize for power consumption and still handle the tasks122suitably.

Additionally, in one or more implementations, the system100adjusts a configuration of active cores104based on one or more characteristics of the applications112actively using the processor102, e.g., licensing fees of those applications that are associated with different numbers of cores. When a particular application112is launched, for instance, the controller106adjusts the active cores104on the fly (e.g., without rebooting) so that a certain number of the cores104are activated. In at least one variation, a “brand string” of the processor102is communicated to the particular application112by another component of the system100(e.g., the operating system110), and the brand string is based on the number of cores104activated while the particular application112executes. In one or more variations, for instance, the brand string communicated when eight cores104of the processor102are activated is different from the brand strings communicated when one core104or sixteen cores104are activated. The brand string is thus capable of indicating different branding configurations of processors in connection with different numbers of active cores, even though the processor102physically includes a set number of total cores104.

Consider an example in which an application112is associated with a first (lower) licensing fee to operate on a processor with a first (lower) number of cores (e.g., an 8-core processor) and is associated with a second (higher) licensing fee to operate on a processor with a second (higher) number of cores (e.g., a 16-core processor). In accordance with the described techniques, the processor102is adjustable on the fly to operate using the first, lower number of cores104, and the operating system110is configurable to provide the application112a brand string that corresponds to a processor having the first, lower number of cores104. In the context of adjusting active cores of a processor “on the fly” (e.g., without rebooting), consider the following discussion ofFIG.2.

FIG.2depicts a non-limiting example200in which the controller adjusts a number of active cores of a processor without rebooting. The example200includes fromFIG.1the processor102, the controller106, and the operating system110. It is to be appreciated that the processor102includes the multiple cores104, but the cores104are not depicted in this example due to space constraints.

The example200includes a variety of example communications and operations between processor102, the controller106, and the operating system110over time. In this example200, the communications and operations are positioned vertically based on time (illustrated on the left hand portion of the example), such that communications and operations closer to a top of the example occur prior to communications or operations further from the top of the example. It follows also that communications or operations closer to a bottom of the example occur subsequent to communications or operations further from the bottom. The example200also depicts various phases and/or states of the system100or portions of the system100. These phases and/or states are also positioned in the example200vertically based on time, such that phases or states closer to a top of the example occur prior to phases, states, or communications further from the top.

Here, the illustrated example200depicts a powered off phase202and a boot phase204of the system100. During the powered off phase202, the system100(and the processor102) is powered off, examples of which include a soft off (e.g., G2/S5 state as specified by Advanced Configuration and Power Interface (ACPI)) and a mechanical off (e.g., G3 state as specified by the ACPI), which require a reboot to return to a working state (e.g., G0/S0 state as specified by ACPI). During the boot phase204, the system100performs various operations, such as hardware initializations, to advance the system100to a working state.

In accordance with the described techniques, the boot phase204includes initialization206of the processor102. By way of example, firmware, such as basic input/output system (BIOS) or the unified extensible firmware interface (UEFI), initializes and tests the processor102and other hardware of the system100(e.g., the memory108) during the boot phase204. In addition, this firmware (e.g., BIOS or UEFI) performs one or more tasks associated with initializing the operating system110, e.g., by loading or executing a boot loader or operating system kernel which initializes the operating system110. The firmware then hands off to the operating system110, which subsequently controls hardware components.

During the boot phase204, the processor102is initialized or otherwise adjusted to operate using a number of active cores104of the processor102. For example, the processor is initialized to operate using first core configuration208. In the first core configuration208a number of cores of the processor102are activated, so that they are subsequently operable to perform the tasks122provided to it by the operating system110. The number of cores104activated in connection with the boot phase204ranges in variations from one core104to all of the cores104. Additionally, the first core configuration208includes a particular selection of the cores104, the selection comprising the number of cores. In an implementation where the processor102includes eight cores104, for example, there are multiple different selections of four cores104. Specifically, there are 70 different possible selections of four activated cores104with an eight-core processor, e.g., a first selection (first, second, third, and fourth cores), a second selection (first, second, third, and fifth cores), a third selection (first, second, third, and sixth cores), a fourth selection (first, second, third, and seventh cores), a fifth selection (first, second, third, and eighth cores), a sixth selection (second, third, fourth, and fifth cores), and so on. It is to be appreciated that the number and selection of active cores104corresponding to the first core configuration208varies without departing from the described techniques.

In accordance with the described techniques, the controller106receives a request116from the operating system to adjust the active cores104, e.g., to switch from the first core configuration to a second core configuration210. By way of example, the request116indicates to switch to a different number of active cores104from the first core configuration208. Alternatively or additionally, the request116indicates to switch to a different selection of active cores104from the first core configuration208. A different selection of active cores104can correspond to a same or different number of cores104as the first core configuration208.

Based on the request116, the controller106provides the core adjustment signals114to the processor102, such as by power gating and/or clock gating the cores104of the processor102. The core adjustment signals114are configured to adjust which cores104are active, such as by activating and deactivating various cores104to obtain the second core configuration210. Responsive to the core adjustment signals114, the processor102is adjusted to operate using the second core configuration210, which has at least one of a different number or selection of active cores104from the first core configuration208. In the illustrated example200, the processor102operates using the second core configuration210subsequent to operating using the first core configuration208. Notably also, the processor102is depicted in the example200operating using the first core configuration208and being adjusted to operate using the second core configuration210without rebooting. Adjusting without rebooting means that there is no additional boot phase depicted while the processor102operates with the first core configuration208, at the switch to the second core configuration210, or while the processor102operates with the second core configuration210.

In addition to adjusting the active cores104without rebooting, the system100informs the operating system110of the adjustments to the cores104, which enables the operating system110to inform the applications112(not depicted in this example) that the active cores104are adjusted, e.g., providing the current core count and/or branding configuration information. In this way, the applications112and the operating system110do not schedule any tasks122on deactivated cores104, and instead use only the activated cores104for performing the tasks122. As discussed above, the controller106informs the operating system110about active cores104using the active core report118, which in one or more implementations indicates activated and deactivated cores using “thermal zones”.

The illustrated example200is also depicted as including tasks122. The operating system110schedules one or more of the tasks122to be performed by the processor102(e.g., its active cores104) while the processor102operates using the first core configuration208. As noted above, examples of the tasks122include threads, processes, and data flows. In at least one example, the processor102also requests and obtains data from the memory108for carrying out the tasks122while operating using the first core configuration208. The operating system110also schedules one or more of the tasks122to be performed by the processor102(e.g., its active cores104) while the processor102operates using the second core configuration210. In accordance with the described techniques, the controller106is further capable of causing the processor102to switch from operating using the second core configuration210to operating using the first core configuration208or using a different core configuration, without rebooting. In the context of enabling a user to request a number and/or selection of active cores104and adjusting which of the cores104are active in order to operate the processor102using the cores104requested, consider the following discussion ofFIGS.3-5.

FIG.3depicts a non-limiting example300of a user interface in one or more implementations. The example300includes a display device302outputting a core control user interface304, which enables a user to control which of the cores104are active and to selectively activate and deactivate the cores104without rebooting.

In the illustrated example300, the user interface304is depicted displaying representations of multiple cores104of the processor102. In one or more implementations, the representations of the multiple cores104are displayed in a manner that is indicative or substantially corresponds to their physical positions on an integrated circuit of the processor102.

Here, the user interface304also includes a respective control306for each of the cores104. The control306is selectable by a user to request activation or deactivation of the respective core104. If a core104is active, for instance, the respective control306is selectable to request that the core104be deactivated. If a core104is not active (e.g., it has been deactivated), however, the respective control306is selectable to request that the core104be activated.

In this example300, the user interface304also includes mode controls308, which are selectable to request a particular mode of operation of the processor102or are transitioned to (and visually emphasized) based on user selection of one or more of the respective controls306. In one or more variations, the different modes correspond to different numbers of active cores104, such as a mode in which all the cores104are active and various modes in which different subsets of the cores104are active. Although not depicted, in one or more implementations, the user interface304includes controls that enable a user to select various optimizations of the processor, such as to optimize which of the cores are activated to optimize for power consumption, thermal conditions, and performance, to name just a few.

In one or more implementations, the system100causes the active cores104to be adjusted responsive to a selection of a single respective control306. For instance, responsive to selection of a single respective control306, the operating system110submits a request116to the controller106indicating to adjust (e.g., activate or deactivate) the respective core104. In response, the controller106adjusts (e.g., activates or deactivates) the respective core104according to the request116without rebooting. The controller106then communicates the active core report118to the operating system110to inform the operating system110about the adjustment.

Alternatively, the system100causes the active cores104to be adjusted responsive to selection of a single mode control308, responsive to selection of one or more of the respective controls306and also selection of an apply control310, and/or responsive to selection of a mode control308and also selection of the apply control310. When a mode control308is selected, in one or more implementations, a component of the system100(e.g., an application112, the operating system110, or the controller106) determines which of the cores104to activate or deactivate in order to adjust the active cores104and enable the processor102to operate using the requested mode. In one example, for instance, the application112, the operating system110, or the controller106references a table which indicates a configuration of active cores104, such that the cores to activate and deactivate is determinable based on a difference between the indicated configuration and currently active cores. Alternatively or in addition, the application112, the operating system110, or the controller106determines which of the cores to activate or deactivate based, at least in part, on conditions of the cores104, such as whether a core104is currently operating, whether a core104was operating with previous time interval, a temperature of a core104, an amount of time a core104has been operating, and so forth.

In any case, the user interface304supports receiving user input (e.g., one or more tap inputs) to request adjustment to active cores104of the processor102on the fly, e.g., without rebooting. Thus, in accordance with the described techniques, responsive to receipt of user input via the user interface304, the operating system110submits a request116to the controller106indicating to adjust (e.g., activate or deactivate) cores104, the controller106adjusts (e.g., activates or deactivates) one or more of the cores104according to the request116without rebooting, and the controller106communicates the active core report118to the operating system110to inform the operating system110about the adjustment. In one or more implementations, the adjustment to the different active cores104(e.g., from the first core configuration208to the second core configuration210) does not substantially affect interaction of a user with a respective computing device. Because the computing device is not rebooted and because the operating system110is informed of the adjustment, for instance, a user is able to continue interacting with the computing device without experiencing significant “downtime,” if any.

Note that in this example300all of the respective controls306include the text ‘Deactivate’ which indicates that all of the respective cores104are active at a time the user interface304is output. Additionally, the mode control308with the text ‘All-Core Mode’ is visually emphasized relative to the other mode controls308. This indicates that the ‘All-Core Mode’ is the “active” mode, e.g., the mode based on which the processor102is configured at the time the user interface304is displayed. In this example, the ‘All-Core Mode’ corresponds to operating the processor102with all of its cores104active. In the context of adjusting the active cores104based on user input, consider the following examples.

FIG.4depicts another non-limiting example400of the user interface in one or more implementations. The example400includes fromFIG.3the display device302displaying the user interface304.

In contrast with the example depicted inFIG.3, the illustrated example400depicts a scenario where not all of the cores are indicated as active in the user interface304. Instead, the illustrated example400represents at402that one of the cores104of the processor102is deactivated. In one example, this core104was previously deactivated based on user input to select the respective control306, e.g., when the respective control306included the text ‘Deactivate’. In this example400, the representation of the core104and the respective control306at402are displayed with one or more characteristics, which differentiate the representation and/or the control from those of activated cores. Here, for instance, the representation of the deactivated core104and the respective control306at402are depicted with visual emphasis which is different from the activated cores. It is to be appreciated that the user interface304is configurable in various ways to differentiate between activated and deactivated cores without departing from the spirit or scope of the described techniques. The respective controls306for activated and deactivated cores are also configurable in various ways (e.g., in addition to or different from text) for activated and deactivated cores104without departing from the spirit or scope of the described techniques.

FIG.5depicts another non-limiting example500of the user interface in one or more implementations. The example500also includes fromFIG.3the display device302displaying the user interface304.

In contrast with the example depicted inFIG.4, the illustrated example500depicts a scenario where multiple cores104are indicated as deactivated in the user interface304. In particular, the illustrated example400represents at502,504,506,508that multiple cores104of the processor102are deactivated, e.g., based on user input in relation to the respective controls306selecting to deactivate those cores104.

Although the user interface304is depicted being displayed, in one or more implementations, a user interface that enables user input to be received for requesting adjustment of active cores of a processor is configured, at least in part, in various ways. In one or more implementations, for example, the user interface is at least partially voice-based, e.g., the user interface receives voice commands and initiates actions based on those commands and/or the user interface audibly outputs information about active cores. It is to be appreciated that user interfaces which enable adjustment to various numbers of active cores without rebooting are configured differently than depicted and discussed herein without departing from the spirit or scope of the described techniques.

Having discussed example systems and user interfaces for core activation and deactivation of a multi-core processor, consider the following example procedures.

FIG.6depicts a procedure in an example600implementation of adjusting a number of active cores of a multi-core processor.

A processor having multiple cores operates using a first core configuration (block602). By way of example, during the boot phase204, the processor102is initialized or otherwise adjusted to operate using a number of active cores104of the processor102. For example, the processor operates using first core configuration208. In the first core configuration208a number of cores of the processor102are activated, so that they are subsequently operable to perform the tasks122provided to it by the operating system110. The number of cores104activated in connection with the boot phase204ranges in variations from one core104to all of the cores104. Additionally, the first core configuration208includes a particular selection of the cores104, the selection comprising the number of cores. In an implementation where the processor102includes eight cores104, for example, there are multiple different selections of four cores104.

A request to switch from the first core configuration to a second core configuration is received (block604). By way of example, the controller106receives a request116from the operating system to adjust the active cores104, e.g., to switch from the first core configuration to a second core configuration210. By way of example, the request116indicates to switch to a different number of active cores104from the first core configuration208. Alternatively or additionally, the request116indicates to switch to a different selection of active cores104from the first core configuration208. A different selection of active cores104can correspond to a same or different number of cores104as the first core configuration208.

Responsive to the request, a switch from the first core configuration to the second core configuration occurs by adjusting a number of active cores of the processor without rebooting (block606). By way of example, based on the request116, the controller106provides the core adjustment signals114to the processor102, such as by power gating and/or clock gating the cores104of the processor102. The core adjustment signals114are configured to adjust which cores104are active, such as by activating and deactivating various cores104to obtain the second core configuration210. Responsive to the core adjustment signals114, the processor102is adjusted to operate using the second core configuration210, which has at least one of a different number or selection of active cores104from the first core configuration208. Notably, the processor102is adjusted to operate using the second core configuration210without rebooting.

It should be understood that many variations are possible based on the disclosure herein. Although features and elements are described above in particular combinations, each feature or element is usable alone without the other features and elements or in various combinations with or without other features and elements.

The various functional units illustrated in the figures and/or described herein (including, where appropriate, the processor102having the multiple cores104, the controller106, the memory108, the operating system110, and the applications112) are implemented in any of a variety of different manners such as hardware circuitry, software or firmware executing on a programmable processor, or any combination of two or more of hardware, software, and firmware. The methods provided are implemented in any of a variety of devices, such as a general purpose computer, a processor, or a processor core. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a graphics processing unit (GPU), a parallel accelerated processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.

In one or more implementations, the methods and procedures provided herein are implemented in a computer program, software, or firmware incorporated in a non-transitory computer-readable storage medium for execution by a general purpose computer or a processor. Examples of non-transitory computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).

Conclusion

Although the systems and techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.