The present disclosure generally relates to the field of electronics. More particularly, some embodiments of the invention generally relate to on-the-fly performance adjustment techniques for solid state storage devices.
Generally, memory used to store data in a computing system can be volatile (to store volatile information) or non-volatile (to store persistent information). Volatile data structures stored in volatile memory are used for temporary or intermediate information that is required to support the functionality of a program during the run-time of the program. On the other hand, persistent data structures stored in non-volatile memory are available beyond the run-time of a program and can be reused. Moreover, new data is typically generated as volatile data first, before the user or programmer decides to make the data persistent. For example, programmers or users may cause mapping (i.e., instantiating) of volatile structures in volatile main memory that is directly accessible by a processor. Persistent data structures, on the other hand, are instantiated on non-volatile storage devices like rotating disks attached to Input/Output (I/O or IO) buses or non-volatile memory based devices like flash memory.
To increase performance, some systems may utilize a Solid State Drive (SSD) that includes non-volatile memory such as flash memory to provide a non-volatile storage solution. Such SSDs generally take less space, weigh less, and are faster than more traditional hard disk drives (HDDs). Furthermore, hard disk drives provide a relatively low-cost storage solution and are used in many computing devices to provide non-volatile storage. Hard disk drives, however, can use a lot of power when compared to Solid State Drives since a hard disk drive needs to spin its rotating disks at a relatively high speed and move disk heads relative to the spinning disks to read/write data. All this physical movement generates heat and increases power consumption.
To this end, some mobile devices are migrating towards solid state drives. Also, some stationary computing systems (such as desktops, workstations, servers, etc.) may utilize such solid state drives to improve performance. However, utilizing the same usage model for solid state drives in different types of computing devices may not always result in an optimal balance between performance and reliability.
The detailed description is provided with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments of the invention may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments of the invention. Further, various aspects of embodiments of the invention may be performed using various means, such as integrated semiconductor circuits (“hardware”), computer-readable instructions organized into one or more programs (“software”), or some combination of hardware and software. For the purposes of this disclosure reference to “logic” shall mean either hardware, software, firmware, or some combination thereof.
Some embodiments provide for on-the-fly performance adjustment techniques for solid state drives. As discussed herein, “on-the-fly” or “dynamic” performance adjustment generally refers performance adjustment without requiring a computing system reboot or Operating System (OS) reboot. Also, such solid state drives may include flash memory (also referred to herein interchangeably as a solid state storage device), Phase Change Memory (PCM), Spin Torque Transfer Random Access Memory (STTRAM), Resistive Random Access Memory, 3D (3-Dimensional) Cross Point Memory, etc. Hence, some embodiments provide methods and/or apparatus to enable dynamic performance control of SSDs. An embodiment enables end-users to dynamically control the performance of SSDs, trading off between performance, reliability, thermal constraints, and/or device lifetime. In one embodiment, a command interface (e.g., via software) allows for making such performance trade-offs on-the-fly, e.g., from within an OS.
In an embodiment, an end-user may utilize techniques/features discussed herein to adjust/tune the performance of a SSD, for example, by enabling SSD over-clocking. Over-clocking generally refers to increasing the operating frequency of a component (such as an SSD) beyond a normal/default operating frequency, e.g., to increase performance. For example, the tuning may be based on OEM (Original Equipment Manufacturer) and/or end-user tolerance to changes in thermal, power, and/or reliability conditions. Such approaches allow for utilizing different characteristics or usage model for SSDs in different types of computing devices to provide a more optimal balance between one or more of performance, reliability, power consumption, thermal conditions, etc.
Moreover, without some embodiments, SSDs used in larger desktop systems with additional power delivery and cooling capability may have to operate within the same constraints of SSDs used in ultra-thin notebooks and their lesser cooling and power delivery capabilities. Also, a file server may have different reliability expectations than a gaming system. To this end, some embodiments allow for a system designer (or savvy user) to have input into these platform tradeoffs. Furthermore, some embodiments provide for a platform-based SSD “Turbo” like capability, e.g., where SSD's performance can be adjusted (also referred to herein as “tuning”), in real-time or during runtime, for one or more (consecutive or non-consecutive) time periods and/or based on various criterion such as: software workload demands, sensor data, and/or environmental conditions. Additionally, Intel® Corporation's Extreme Tuning Utility (XTU) enables end-users to over-clock the Central Processing Unit (CPU), Graphics Processing Unit (GPU), and/or system memory to achieve higher system performance. This utility may be extended in an embodiment to allow for end-users to over-clock their SSDs, e.g., resulting in improved performance for storage I/O (Input/Output) bound workloads. Further, while allowing the ability to over-clock SSDs, some embodiments avoid the potential for extensive data loss (e.g., when a solid state storage device controller stops operating). Moreover, while some embodiments herein discuss techniques applied to SSDs, it is envisioned that the same or similar techniques may also be applied to other types of non-volatile memory devices.
The techniques discussed herein may be provided in various computing systems (e.g., including smart phones, tablets, portable game consoles, Ultra-Mobile Personal Computers (UMPCs), etc.), such as those discussed with reference to
In an embodiment, the processor 102-1 may include one or more processor cores 106-1 through 106-M (referred to herein as “cores 106,” or more generally as “core 106”), a cache 108 (which may be a shared cache or a private cache in various embodiments), and/or a router 110. The processor cores 106 may be implemented on a single integrated circuit (IC) chip. Moreover, the chip may include one or more shared and/or private caches (such as cache 108), buses or interconnections (such as a bus or interconnection 112), logic 120, memory controllers (such as those discussed with reference to
In one embodiment, the router 110 may be used to communicate between various components of the processor 102-1 and/or system 100. Moreover, the processor 102-1 may include more than one router 110. Furthermore, the multitude of routers 110 may be in communication to enable data routing between various components inside or outside of the processor 102-1.
The cache 108 may store data (e.g., including instructions) that are utilized by one or more components of the processor 102-1, such as the cores 106. For example, the cache 108 may locally cache data stored in a memory 114 for faster access by the components of the processor 102. As shown in
As shown in
Furthermore, logic 125 may be coupled to one or more sensors 150 to receive information (e.g., in the form of one or more bits or signals) to indicate the status of or values detected by the one or more sensors 150. The sensor(s) 150 may be provided proximate to components of system 100 (or other computing systems discussed herein such as those discussed with reference to other figures including 5-7, for example), such as the cores 106, interconnections 104 or 112, components outside of the processor 102, SSD, SSD bus, SATA bus, logic 125, etc., to sense variations in various factors affecting power/thermal behavior of the system/platform, such as temperature, operating frequency, operating voltage, power consumption, and/or inter-core communication activity, etc.
At an operation 208, a driver command is passed to initiate the turning/change to the SSD performance (e.g., via a storage device driver such as a Serial Advanced Technology Attachment (SATA) driver). The driver command is passed to a SATA controller logic 210 (e.g., include in a Peripheral Control Hub (PCH) or other hardware) via a SATA bus. In an embodiment, the SATA controller 210 is the same or similar to the logic 125 of
Moreover, some embodiments provide for on-the-fly adjusting of performance characteristics for solid state storage devices (including SSDs) by providing the ability to make changes without a system or OS reboot. It allows a plurality of real-time tuning options via software and/or hardware communication and control mechanisms to manage dynamic tuning as discussed with reference to
For example,
Accordingly, some embodiments enable solid state storage device over-clocking by tuning the frequency of the device controller (e.g., logic 125 of
Furthermore, such techniques may be used to enable an “SSD Turbo” feature where platform logic (such as software and/or firmware) can dynamically modify SSD performance to balance/change performance versus battery life in particular form-factors and operating conditions. Also, some embodiments prevent catastrophic failures (e.g., caused by malicious attacks) by providing recovery methods (such as discussed with reference to
Referring to
Various embodiments use SCT and/or ATA (Advanced Technology Attachment) commands to communicate with SSDs to invoke the tuning or over-clocking. The SCT command may be transmitted via a SATA command sent to an SSD. Table 1 below lists SCT commands that may be used in some embodiments (which may be vendor specific in some embodiments). One embodiment uses SCT commands for the NAND timing value, the maximum controller frequency value, and accumulated power value. In an embodiment, an SSD over-clocking lock command is used to prevent users from over-clocking the drive via software unless explicitly unlocked (e.g., helping prevent malicious code or some users from doing harm). Hence, locking prevents tuning or over-clocking and unlocking allows changes. The locking command may cause setting (or clearing depending on implementation) of a lock status bit in some storage device (such as a memory (including memories discussed with reference to
Furthermore, ATA commands may be used to read the SSD's model/serial numbers and other identification information (e.g., from the ATA addresses in a storage device, firmware, etc.). The temperature of the SSD may also be monitored via ATA command (e.g., via one or more of the sensors 150 of
Some embodiments make use of the existing SCT and ATA command protocols; however, new commands are added for the unique tuning features discussed herein (e.g., such as shown in Table 1). The majority of commands used are SCT based commands. For example, with respect to the last line of Table 1, the Drive Over-clocking Lockout command is created (and a half dozen others shown in Table 1) to manage the ability to tune SSD performance on-the-fly and in real-time (rather than via hard coded firmware that SSD manufacturers would use to develop/test their solutions, for example).
Moreover, some embodiments use ATA commands, e.g., for telemetry as inputs to feedback loops where intelligent software dynamically changes tuning parameters. For example, when pushing the boundaries of performance, the storage device may heat-up and ATA commands to retrieve temperature data can be used to help detect this situation and reduce one or more tuning parameters to keep the drive in healthy operating conditions.
Referring to
Moreover, tuning may be initiated by system software (e.g., application, utility, etc.) or system BIOS. Also, tuning may be initiated manually (e.g., via a user GUI) or automatically (e.g., by intelligent logic, including software and/or firmware). Commands to initiate this tuning may utilize the SCT or ATA protocols such as discussed with reference to Table 1 above. For example, when initiated from within the OS, the commands pass through the storage device driver (which may be stored in memory 114 of
In an embodiment, controller logic 482 can change its own clock/operating frequency by changing the ratio (a.k.a., multiplier) to its existing clock. For example, if the controller's nominal clock is 33.3 MHz and normally fixed ratio is 3 for a 100 MHz effective frequency, changing the ratio to 4 would provide a higher (e.g., 133 MHz) clock frequency which can accelerate performance. Similarly, the clock/operating frequency of one or more of the bus(es) or channel(s) coupled between the memory modules 492-1 to 492-n and memory controller logic 786, as well as operating/clock frequencies of one or more of the memory modules 492-1 to 492-n may be changed in various embodiments. Moreover, while an example of changing ratios is provided, it may also be possible to change the nominal clock frequency directly instead (or in addition thereto). In such cases, the flow would be similar and may optionally include communication/control of an external clock source.
In accordance with some embodiments, the knobs used may include one or more of: (a) controller logic 125 frequency, e.g., derived from system PLL (Phase Locked Loop) timing (e.g., between about 400 MHz to 625 MHz); (b) SSD bus frequency that may include the SATA bus coupled to the SSD, an internal bus in the SSD that is coupled to the non-volatile memory cells of the SSD, etc. (e.g., switching between about 83 MHz and 100 MHz); and/or (c) power mode (such as low, typical, unconstrained, etc.).
Additionally, in accordance with some embodiments, the values being monitored may include one or more of: temperature, controller logic 125 frequency, flash memory bus frequency (e.g., which may be the same as controller logic 125 frequency), solid state storage device operating frequency, and/or accumulated power.
Furthermore, some embodiments provide for a platform-based solid state storage device “Turbo” like capability, e.g., where solid state storage devices performance can be increased, e.g., in real-time, for one or more (consecutive or non-consecutive) time periods and/or based on various criterion such as: software workload demands, sensor data, and/or environmental conditions. The SSD Turbo feature can be built by putting the SSD tuning and over-clocking building blocks discussed herein together. Hence, some embodiments provide a framework, for the first time, which allows dynamic changes to SSD performance, including monitoring frequency(ies), power consumption, and closed-loop parameters. In this fashion, the general principle of Turbo may be applied to SSDs, e.g., speeding up SSDs to meet peak demands and slowing down SSDs (utilizing lower power levels) when the demand is reduced.
In an embodiment, one or more of the processors 502 may be the same or similar to the processors 102 of
A chipset 506 may also communicate with the interconnection network 504. The chipset 506 may include a graphics and memory control hub (GMCH) 508. The GMCH 508 may include a memory controller 510 (which may be the same or similar to the memory controller 120 of
The GMCH 508 may also include a graphics interface 514 that communicates with a graphics accelerator 516. In one embodiment of the invention, the graphics interface 514 may communicate with the graphics accelerator 516 via an accelerated graphics port (AGP). In an embodiment of the invention, a display 517 (such as a flat panel display, touch screen, etc.) may communicate with the graphics interface 514 through, for example, a signal converter that translates a digital representation of an image stored in a storage device such as video memory or system memory into display signals that are interpreted and displayed by the display. The display signals produced by the display device may pass through various control devices before being interpreted by and subsequently displayed on the display 517.
A hub interface 518 may allow the GMCH 508 and an input/output control hub (ICH) 520 to communicate. The ICH 520 may provide an interface to I/O devices that communicate with the computing system 500. The ICH 520 may communicate with a bus 522 through a peripheral bridge (or controller) 524, such as a peripheral component interconnect (PCI) bridge, a universal serial bus (USB) controller, or other types of peripheral bridges or controllers. The bridge 524 may provide a data path between the CPU 502 and peripheral devices. Other types of topologies may be utilized. Also, multiple buses may communicate with the ICH 520, e.g., through multiple bridges or controllers. Moreover, other peripherals in communication with the ICH 520 may include, in various embodiments of the invention, integrated drive electronics (IDE) or small computer system interface (SCSI) hard drive(s), USB port(s), a keyboard, a mouse, parallel port(s), serial port(s), floppy disk drive(s), digital output support (e.g., digital video interface (DVI)), or other devices.
The bus 522 may communicate with an audio device 526, one or more disk drive(s) 528, and a network interface device 530 (which is in communication with the computer network 503, e.g., via a wired or wireless interface). As shown, the network interface device 530 may be coupled to an antenna 531 to wirelessly (e.g., via an Institute of Electrical and Electronics Engineers (IEEE) 802.11 interface (including IEEE 802.11a/b/g/n, etc.), cellular interface, 3G, 5G, LPE, etc.) communicate with the network 503. Other devices may communicate via the bus 522. Also, various components (such as the network interface device 530) may communicate with the GMCH 508 in some embodiments of the invention. In addition, the processor 502 and the GMCH 508 may be combined to form a single chip. Furthermore, the graphics accelerator 516 may be included within the GMCH 508 in other embodiments of the invention.
Furthermore, the computing system 500 may include volatile and/or nonvolatile memory (or storage). For example, nonvolatile memory may include one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), a disk drive (e.g., 528), a floppy disk, a compact disk ROM (CD-ROM), a digital versatile disk (DVD), flash memory, a magneto-optical disk, or other types of nonvolatile machine-readable media that are capable of storing electronic data (e.g., including instructions).
As illustrated in
In an embodiment, the processors 602 and 604 may be one of the processors 502 discussed with reference to
As shown in
The chipset 620 may communicate with a bus 640 using a PtP interface circuit 641. The bus 640 may have one or more devices that communicate with it, such as a bus bridge 642 and I/O devices 643. Via a bus 644, the bus bridge 642 may communicate with other devices such as a keyboard/mouse 645, communication devices 646 (such as modems, network interface devices, or other communication devices that may communicate with the computer network 503, as discussed with reference to network interface device 530 for example, including via antenna 531), audio I/O device, and/or a data storage device 648. The data storage device 648 may store code 649 that may be executed by the processors 602 and/or 604.
In some embodiments, one or more of the components discussed herein can be embodied as a System On Chip (SOC) device.
As illustrated in
The I/O interface 740 may be coupled to one or more I/O devices 770, e.g., via an interconnect and/or bus such as discussed herein with reference to other figures. I/O device(s) 770 may include one or more of a keyboard, a mouse, a touchpad, a display, an image/video capture device (such as a camera or camcorder/video recorder), a touch screen, a speaker, or the like. Furthermore, SOC package 702 may include/integrate the logic 125 in an embodiment. Alternatively, the logic 125 may be provided outside of the SOC package 702 (i.e., as a discrete logic).
The following examples pertain to further embodiments. Example 1 includes an apparatus comprising: controller logic to control access to one or more non-volatile memory devices; wherein the controller logic is to cause a change in an operational frequency of one or more of: the controller logic, a bus that couples the one or more non-volatile memory devices to the controller logic, and one or more of the one or more non-volatile memory devices, wherein the controller logic is to cause the change in the operational frequency in response to a command. Example 2 includes the apparatus of example 1, wherein the one or more non-volatile memory devices are to comprise one or more of: a solid state storage device, a phase change memory, a 3D (3-Dimensional) cross point memory, a resistive random access memory, and a spin torque transfer random access memory. Example 3 includes the apparatus of example 1, wherein the command is to comprise a smart command transport command. Example 4 includes the apparatus of example 1, wherein the command is to be issued during run-time to cause the change without a system or operating system reboot. Example 5 includes the apparatus of example 1, wherein the controller logic is to refrain from causing the change in response to a lock command. Example 6 includes the apparatus of example 1, wherein the controller logic is to refrain from causing the change in response to a value of a lock status bit. Example 7 includes the apparatus of example 1, wherein the controller logic is to cause a system reset in response to detection of an unstable operating condition associated with the one or more non-volatile memory devices. Example 8 includes the apparatus of example 1, wherein the command is to be issued by a user interface or an automated software application. Example 9 includes the apparatus of example 1, wherein the one or more non-volatile memory devices are on a same integrated circuit die. Example 10 includes the apparatus of example 1, wherein one or more of the controller logic, the one or more non-volatile memory devices, and a processor core are on a same integrated circuit die. Example 11 includes the apparatus of example 1, wherein a memory controller is to comprise the controller logic.
Example 12 includes a method comprising: controlling access to one or more non-volatile memory devices via controller logic; and causing a change in an operational frequency of one or more of: the controller logic, a bus that couples the one or more non-volatile memory devices to the controller logic, and one or more of the one or more non-volatile memory devices at the controller logic, wherein the controller logic causes the change in the operational frequency in response to a command. Example 13 includes the method of example 12, wherein the one or more non-volatile memory devices comprise one or more of: a solid state storage device, a phase change memory, a 3D (3-Dimensional) cross point memory, a resistive random access memory, and a spin torque transfer random access memory. Example 14 includes the method of example 12, wherein the command comprises a smart command transport command. Example 15 includes the method of example 12, further comprising issuing the command during run-time to cause the change without a system or operating system reboot. Example 16 includes the method of example 12, further comprising the controller logic refraining from causing the change in response to a lock command. Example 17 includes the method of example 12, further comprising the controller logic refraining from causing the change in response to a value of a lock status bit. Example 18 includes the method of example 12, further comprising the controller logic causing a system reset in response to detection of an unstable operating condition associated with the one or more non-volatile memory devices. Example 19 includes the method of example 12, further comprising issuing the command by a user interface or an automated software application.
Example 20 includes a system comprising: one or more non-volatile memory devices; and at least one processor core to access the one or more non-volatile memory devices via controller logic, wherein the controller logic is to cause a change in an operational frequency of one or more of: the controller logic, a bus that couples the one or more non-volatile memory devices to the controller logic, and one or more of the one or more non-volatile memory devices, wherein the controller logic is to cause the change in the operational frequency in response to a command. Example 21 includes the system of example 20, wherein the one or more non-volatile memory devices are to comprise one or more of: a solid state storage device, a phase change memory, a 3D (3-Dimensional) cross point memory, a resistive random access memory, and a spin torque transfer random access memory. Example 22 includes the system of example 20, wherein the command is to comprise a smart command transport command. Example 23 includes the system of example 20, wherein the command is to be issued during run-time to cause the change without a system or operating system reboot. Example 24 includes the system of example 20, wherein one or more of the controller logic, the one or more non-volatile memory devices, and the at least one processor core are on a same integrated circuit die. Example 25 includes the system of example 20, further comprising a touch screen to display data stored in the one or more non-volatile memory devices.
Example 26 includes an apparatus to adjust performance for solid state storage devices on-the-fly, the apparatus comprising: means for controlling access to one or more non-volatile memory devices coupled to controller logic; and means for causing a change in an operational frequency of one or more of: the controller logic, a bus that couples the one or more non-volatile memory devices to the controller logic, and one or more of the one or more non-volatile memory devices at the controller logic, wherein the controller logic causes the change in the operational frequency in response to a command. Example 27 includes the apparatus of example 26, comprising means for issuing the command during run-time to cause the change without a system or operating system reboot. Example 28 includes the apparatus of example 26, comprising means for refraining from causing the change in response to a lock command. Example 29 includes the apparatus of example 26, comprising means for refraining from causing the change in response to a value of a lock status bit.
Example 30 includes a computer-readable medium comprising one or more instructions that when executed on a processor configure the processor to perform one or more operations of any of examples 12 to 19.
In various embodiments of the invention, the operations discussed herein, e.g., with reference to
Additionally, such tangible computer-readable media may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals (such as in a carrier wave or other propagation medium) via a communication link (e.g., a bus, a modem, or a network connection).
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least an implementation. The appearances of the phrase “in one embodiment” in various places in the specification may or may not be all referring to the same embodiment.
Also, in the description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. In some embodiments of the invention, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other. “Coupled” may mean that two or more elements are in direct physical or electrical contact. However, “coupled” may also mean that two or more elements may not be in direct contact with each other, but may still cooperate or interact with each other.
Thus, although embodiments of the invention have been described in language specific to structural features and/or methodological acts, it is to be understood that claimed subject matter may not be limited to the specific features or acts described. Rather, the specific features and acts are disclosed as sample forms of implementing the claimed subject matter.
This application relates to and claims priority from U.S. Provisional Patent Application No. 61/829,983, entitled “ON-THE-FLY PERFORMANCE ADJUSTMENT FOR SOLID STATE STORAGE DEVICES,” filed on May 31, 2013.
Number | Date | Country | |
---|---|---|---|
61829983 | May 2013 | US |