Improve the cache hit ratio for selected volumes in the storage system

Abstract

A method for improving cache hit rates for selected volumes when using synchronous I / O is disclosed. In one embodiment, the method includes establishing a first set of non-preferred storage elements from non-preferred storage regions in a cache. The method further establishes a second set of preferred storage elements from preferred storage regions in the cache. The method calculates the expected lifetime of the non-preferred storage elements in the cache before eviction. The method also implements an eviction policy for the cache in which preferred storage elements are retained in the cache longer than the expected lifetime of the non-preferred storage elements. A corresponding system and computer program product are also disclosed.

Description

Technical Field

[0001] The present invention relates to systems and methods for improving cache hit rates for selected volumes within a storage system. Background Art

[0002] When an application performs an I / O request, several processes may have to be performed before the request is completed. These processes affect I / O latency, which can be a significant portion of application response time. zHyperLink is a technology designed to reduce I / O latency by providing a fast, reliable, and direct communication path between the host system and the storage system. This is achieved by installing zHyperLink adapters on the z / OS host system and the storage system and connecting the components together using zHyperLink cables. This configuration creates a point-to-point connection between the host system and the storage system, which is different from zHigh-Performance (zHPF), which reduces I / O response times by up to a factor of 10. This low response time is achieved by using synchronous I / O requests, which reduce the amount of time required for certain functions, such as I / O interrupts and z / OS scheduled operations.

[0003] Standard I / O processing available using technologies such as zHPF requires I / O operations to perform a series of time-consuming tasks, such as z / OS dispatch, interrupt handling, CPU queuing, and L1 / L2 processor cache reloads. These and other tasks required for I / O processing can make I / O response times relatively long compared to transferring data within virtual memory, where response times can be 130+ microseconds plus interrupt handling and CPU dispatch times.

[0004] Typically, with zHyperLink or synchronous I / O, when performing synchronous I / O operations, the CPU on the host system waits or "spins" until the I / O completes or a timeout value is reached. zHyperLink can significantly reduce the time required to complete I / O because dispatching, interrupt handling, CPU queue time, and CPU cache reload activity are no longer required. This saves processor time associated with the two context switches involved in normal I / O operations: putting the thread to sleep and then rescheduling it, and executing the I / O interrupt.

[0005] In order to achieve the improved I / O response times associated with synchronous I / O (e.g., zHyperLink), the code path used to handle I / O needs to be highly optimized. Any condition that delays a synchronous I / O operation (e.g., a cache miss) can result in a notification being returned to the host system and the operation being retried using a slower communication path (e.g., zHPF). Synchronous I / O will only succeed if the microcode can complete the synchronous I / O operation within a very short amount of time (e.g., 10-30 microseconds). If the synchronous I / O operation cannot complete within that amount of time, the synchronous I / O operation may fail and the host system may need to retry the operation on a non-optimal path, such as FICON.

[0006] In view of the foregoing, what is needed is a system and method for improving the cache hit rate of a selected volume when using synchronous I / O technologies such as zHyperLink. Such a system and method would ideally reduce or prevent delays that may hinder the execution of synchronous I / O operations. Summary of the Invention

[0007] The present invention has been developed in response to the state of the art, and more particularly, in response to problems and needs in the art that have not yet been fully addressed by currently available systems and methods. Accordingly, a system and method have been developed for improving the cache hit rate of selected volumes when using synchronous I / O processes. The features and advantages of the present invention will become more apparent from the following description and the appended claims, or may be learned by practice of the invention as described hereinafter.

[0008] Consistent with the foregoing, a method for improving a cache hit rate for a selected volume when using synchronous I / O is disclosed. In one embodiment, such a method includes establishing a first set of non-preferred storage elements from a non-preferred storage region in a cache. The method further establishes a second set of preferred storage elements from a preferred storage region in the cache. The method calculates an expected lifetime for the non-preferred storage elements to reside in the cache before being evicted. The method also implements an eviction policy for the cache, wherein preferred storage elements are retained in the cache for at least some multiple of the expected lifetime of the non-preferred storage elements. In certain embodiments, the method calculates the expected lifetime by subtracting the timestamp of the least recently used non-preferred storage element in the first set from the timestamp of the most recently used non-preferred storage element in the first set. The disclosed method reduces or prevents delays that may impair the operation of a synchronous I / O (e.g., zHyperLink) process when accessing a preferred storage region.

[0009] Corresponding systems and computer program products are also disclosed and claimed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to facilitate an understanding of the advantages of the present invention, a more particular description of the invention, briefly described above, will be rendered by reference to specific embodiments shown in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of the scope of the invention, embodiments of the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0011] Figure 1 is a high-level block diagram illustrating one example of a network environment in which systems and methods according to the present invention may be implemented;

[0012] Figure 2 It is shown for Figure 1 A high-level block diagram of an example of a storage system in a network environment;

[0013] Figure 3 is a high-level block diagram illustrating different communication paths between a host system and a storage system;

[0014] Figure 4 is a high-level block diagram illustrating a system for improving cache hit rates for selected volumes when using synchronous I / O;

[0015] Figure 5 is a high-level block diagram illustrating various exemplary sub-modules within an optimization module according to the present invention;

[0016] Figure 6 is a flow chart illustrating one embodiment of a method for evicting storage elements from a cache in order to free up space in the cache while providing preference to preferred storage elements;

[0017] Figure 7 is a high-level block diagram illustrating a host system sending commands and / or lists to a storage system to specify which volumes should be considered preferred and non-preferred;

[0018] Figure 8 is a flow chart illustrating an alternative method for evicting storage elements from a cache in order to free up space in the cache while providing preference to preferred storage elements;

[0019] Figure 9 is a high-level block diagram illustrating a host system sending a residency multiplier to a storage system to indicate how strong a cache preference to apply to a preferred volume;

[0020] Figure 10 is a high-level block diagram illustrating a priority adjustment module for adjusting cache priority of a preferred volume;

[0021] Figure 11 is a high-level block diagram illustrating a first example of a list of preferred volumes and associated residency multipliers;

[0022] Figure 12 is a high-level block diagram illustrating a second example of a list of preferred volumes and associated residency multipliers;

[0023] Figure 13 is a high-level block diagram showing an LRU list for each set of preferred volumes having the same residency multiplier, and an LRU list for non-preferred volumes; and

[0024] Figure 14 is shown for use such as Figure 13 Flowchart of a method for evicting storage elements from a cache by an LRU list such as the LRU list shown in . DETAILED DESCRIPTION

[0025] It will be readily understood that the components of the present invention, as generally described and illustrated in the drawings herein, may be arranged and designed in a variety of different configurations. Accordingly, the following more detailed description of the embodiments of the present invention, as represented in the drawings, is not intended to limit the scope of the invention as claimed, but rather merely represents certain examples of presently contemplated embodiments according to the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like components are represented by like numerals throughout.

[0026] The present invention may be embodied as a system, method, and / or computer program product.The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to perform various aspects of the present invention.

[0027] Computer readable storage medium can be the tangible device that can retain and store the instruction used for instruction execution device.Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device or above-mentioned any suitable combination.The non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device such as punch card or the projection structure in the groove with instruction recorded thereon and any suitable combination of the above.Computer readable storage medium as used herein should not be interpreted as temporary signal itself, such as radio wave or other free propagation electromagnetic wave, electromagnetic wave (for example, light pulse through fiber optic cable) propagated by waveguide or other transmission medium or electric signal emitted by wire.

[0028] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0029] Computer readable program instructions for carrying out operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as the "C" programming language or similar programming languages).

[0030] The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (for example, using an internet service provider through the internet). In certain embodiments, an electronic circuit comprising, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can perform computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit so as to perform various aspects of the present invention.

[0031] The present invention will be described below with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0032] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in the flowchart and / or block diagram or multiple blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in the flowchart and / or block diagram or multiple blocks.

[0033] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in or in multiple boxes in the flowchart and / or block diagram.

[0034] See also Figure 1 , an example of a network environment 100 is shown. Network environment 100 is presented to illustrate an example of an environment in which the systems and methods according to the present invention may be implemented. Network environment 100 is presented as an example and not as a limitation. In fact, in addition to the network environment 100 shown, the systems and methods disclosed herein may be applicable to a variety of different network environments.

[0035] As shown, network environment 100 includes one or more computers 102, 106 interconnected via a network 104. Network 104 may include, for example, a local area network (LAN) 104, a wide area network (WAN) 104, the Internet 104, an intranet 104, and the like. In some embodiments, computers 102, 106 may include both client computers 102 and server computers 106 (also referred to herein as "host systems" 106). Typically, client computers 102 initiate communication sessions, while server computers 106 await requests from client computers 102. In some embodiments, computers 102 and / or servers 106 may be connected to one or more internal or external direct-attached storage systems 110a (e.g., arrays of hard disk drives, solid-state drives, tape drives, and the like). These computers 102, 106 and direct-attached storage systems 110a may communicate using protocols such as ATA, SATA, SCSI, SAS, Fibre Channel, and the like.

[0036] In some embodiments, the network environment 100 may include a storage network 108 behind the server 106, such as a storage area network (SAN) 108 or a LAN 108 (e.g., when network attached storage is used). This network 108 may connect the server 106 to one or more storage systems, such as an array of hard disk drives or solid-state drives 110b, a tape library 110c, individual hard disk drives 110d or solid-state drives 110d, a tape drive 110e, a CD-ROM library, etc. To access the storage system 110, the host system 106 may communicate via a physical connection from one or more ports on the host 106 to one or more ports on the storage system 110. The connection may be through a switch, a fabric, a direct connection, etc. In some embodiments, the server 106 and the storage system 110 may communicate using a networking standard such as Fibre Channel (FC).

[0037] See also Figure 2 , shows one embodiment of a storage system 110 including an array of hard disk drives 204 and / or solid-state drives 204. As shown, the storage system 110 includes a storage controller 200, one or more switches 202, and one or more storage drives 204, such as hard disk drives 204 or solid-state drives 204 (such as flash-based drives 204). The storage controller 200 can enable one or more hosts 106 (e.g., open systems and / or mainframe servers 106 running an operating system such as z / OS, zVM, etc.) to access data in the one or more storage drives 204.

[0038] In selected embodiments, the storage controller 200 includes one or more servers 206. The storage controller 200 may also include a host adapter 208 and a device adapter 210 to connect the storage controller 200 to the host devices 106 and the storage drives 204, respectively. The multiple servers 206a, 206b may provide redundancy to ensure that data is always available to the connected hosts 106. Thus, when one server 206a fails, another server 206b may pick up the I / O load of the failed server 206a to ensure that I / O can continue between the hosts 106 and the storage drives 204. This process may be referred to as "failover."

[0039] In selected embodiments, each server 206 may include one or more processors 212 and memory 214. Memory 214 may include volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, EPROM, EEPROM, hard disk, flash memory, etc.). In certain embodiments, the volatile and non-volatile memory may store software modules that run on the processor(s) 212 and are used to access data in the storage drives 204. These software modules may manage all read and write requests to the logical volumes in the storage drives 204.

[0040] In selected embodiments, the memory 214 includes a cache 218, such as a DRAM cache 218. Whenever a host 106 (e.g., an open system or mainframe server 106) performs a read operation, the server 206 performing the read can retrieve the data from the storage drive 204 and save the data in its cache 218 if needed again. If the host 106 requests the data again, the server 206 can fetch the data from the cache 218 instead of from the storage drive 204, saving time and resources. Similarly, when a host 106 performs a write, the server 106 receiving the write request can store the write in its cache 218 and later flush the write to the drive 204. While the write is stored in the cache 218, it can also be stored in the non-volatile storage (NVS) 220 of the peer server 206 so that the write can be recovered by the peer server 206 in the event of a failure of the first server 206. In some embodiments, the NVS 220 is implemented as battery-backed memory in the peer server 206.

[0041] With similar Figure 2 An example of a storage system 110 of the illustrated architecture is the IBM DS8000™ enterprise storage system. The DS8000™ is a high-performance, high-capacity storage controller that provides disk storage designed to support continuous operation. However, the systems and methods disclosed herein are not limited to operating with the IBM DS8000™ enterprise storage system 110, but rather can operate with any comparable or similar storage system 110, regardless of the manufacturer, product name, or component or component names associated with the system 110. Furthermore, any storage system that can benefit from one or more embodiments of the present invention is considered to fall within the scope of the present invention. Therefore, the IBM DS8000™ is presented by way of example and is not intended to be limiting.

[0042] See also Figure 3When an I / O request is executed by an application residing on a host system 106, several processes may be performed to complete the request. These processes may affect I / O latency and application response time. zHyperLink is a technology designed to reduce I / O latency by providing a fast, reliable, and direct communication path 300 between the host system and the storage system 110. This can be achieved by installing zHyperLink adapters on the host system 106 and the storage system 110 and connecting the components using zHyperLink cables. This configuration creates a point-to-point connection 300 between the host system 106 and the storage system controller 200. This is similar to using, for example, zHyperLink for high performance storage. This technique can reduce I / O response times by up to ten times compared to conventional communication paths 302, such as the zHPF communication path 302. Such low response times can be achieved by using synchronous I / O requests, which reduces the amount of time required for certain functions, such as I / O interrupts and I / O scheduling operations.

[0043] Standard I / O processing available using technologies such as zHPF requires I / O operations to perform a series of time-consuming tasks, such as z / OS dispatch, interrupt handling, CPU queuing, and L1 / L2 processor cache reloads. These and other tasks required for I / O processing can make I / O response times relatively long compared to transferring data within virtual memory, where response times can be 130+ microseconds plus interrupt handling and CPU dispatch times.

[0044] Using zHyperLink, when performing synchronous I / O over higher-performance communication path 300, the CPU on host system 106 can wait or "spin" until the I / O completes or a timeout value is reached. zHyperLink can significantly reduce the time required to complete I / O because dispatching, interrupt handling, CPU queue time, and CPU cache reload activity are no longer required. This reduces the processor time required to perform two context switches during normal I / O operations, putting a thread to sleep and then rescheduling it, and executing an I / O interrupt.

[0045] In order to achieve the improved I / O response times associated with synchronous I / O, the code path used to process I / O needs to be highly optimized. Any condition that delays a synchronous I / O operation (e.g., a cache miss) may cause a notification to be returned to the host system 106 and the operation to be retried via a slower communication path 302 (e.g., zHPF). Synchronous I / O on the higher-performance communication path 300 typically succeeds only if the microcode can complete the synchronous I / O operation within a very short amount of time (such as 10-30 microseconds). If the synchronous I / O operation cannot be completed within that amount of time, the synchronous I / O operation may fail, and the host system 106 may need to retry the operation on a non-optimal path 302 (such as FICON).

[0046] See also Figure 4 , while continuing to see in general Figure 3 In order to perform synchronous I / O on data stored in volumes 304 of the storage system 110, the requested data is ideally contained in the cache 218. A cache miss may cause the synchronous I / O operation to fail and be retried via a slower communication path 302 (e.g., zHPF). To improve the cache hit rate of data accessed using synchronous I / O, in some embodiments, the volumes 304 on the storage system 110 may be divided into preferred volumes 304a and non-preferred volumes 304b. Preferred volumes 304a may be those volumes 304 that are preferably accessed using synchronous I / O. These volumes may be volumes 304 that are considered more important or critical, or contain performance-important or critical data (e.g., directories, etc.). In contrast, non-preferred volumes 304b may be any volume 304 that is not designated as a preferred volume 304a.

[0047] like Figure 4 As shown, volumes 304 may be composed of storage elements 402, such as tracks. Storage elements 402 from preferred volume 304a may be designated as preferred storage elements 402a, while storage elements 402 from non-preferred volume 304b may be designated as non-preferred storage elements 402b. At any given time, cache 218 of storage system 110 may store a first set 404b of non-preferred storage elements 402b and a second set 404a of preferred storage elements 402a from non-preferred volume 304b and preferred volume 304a, respectively. Because preferred volume 304a is one of the volumes 304 that prioritizes synchronous I / O, preferred storage elements 402a may be prioritized in cache 218 over non-preferred storage elements 402b. This ideally improves the cache hit rate for preferred storage elements 402a, thereby optimizing synchronous I / O and increasing the percentage of successfully completed synchronous I / O operations.

[0048] To provide preferential treatment of preferred storage elements 402a over non-preferred storage elements 402b in the cache 218, an optimization module 400 may be provided. Among other things, the optimization module 400 may provide functionality for specifying which volumes 304 are preferred and non-preferred, and for implementing a cache eviction policy in which preferred storage elements 402a remain in the cache 218 longer than non-preferred storage elements 402b. The optimization module 400 and its functionality will be incorporated into the Figure 5 Discuss in more detail.

[0049] See also Figure 5 , illustrates a high-level block diagram showing the optimization module 400 and associated sub-modules. The optimization module 400 and associated sub-modules can be implemented in hardware, software, firmware, or a combination thereof. The optimization module 400 and associated sub-modules are presented by way of example and not limitation. In different embodiments, more or fewer sub-modules may be provided. For example, the functionality of some sub-modules may be combined into a single sub-module or a smaller number of sub-modules, or the functionality of a single sub-module may be distributed across several sub-modules. Although the optimization module 400 and associated sub-modules are shown within the storage system 110, all functionality need not be implemented within the storage system 110 and is not limited to implementation within the storage system 110. Therefore, the location of the optimization module 400 and associated sub-modules is provided by way of example and not limitation.

[0050] As shown, the optimization module 400 includes one or more of a setup module 500, an adjustment module 502, a life expectancy determination module 504, a residency determination module 506, and a cache eviction module 508. The setup module 500 can be configured to designate preferred volumes 304a and non-preferred volumes 304b, as previously discussed. In some embodiments, the host system 106 communicates these designations to the storage system 110. In some embodiments, preferred / non-preferred volumes 304 are established using online commands or configuration lists. In other embodiments, functionality can be built into the host system 106 to determine which volumes 304 are preferred / non-preferred. For example, the host system 106 can observe I / O patterns and can determine that certain volumes 304 should or should be accessed using a faster synchronous I / O process. The host system 106 can add these volumes 304 to the set of preferred volumes 304a.

[0051] The adjustment module 502 can adjust which volumes 304 are preferred / non-preferred. For example, over time, the access patterns or data importance on the volumes 304 may change. In some embodiments, the adjustment module 502 can adjust which volumes 304 are considered preferred / non-preferred as these access patterns or data importance change. Alternatively, the adjustment module 502 can enable a user to manually adjust which volumes 304 are considered preferred or non-preferred. In some embodiments, as will be combined with Figure 7 As explained in greater detail, the host system 102 periodically sends commands and / or lists to the storage system 110 to change or update which volumes 304 are considered preferred or non-preferred.

[0052] The life expectancy determination module 504 can be configured to determine the life expectancy (i.e., residency time) of storage elements (e.g., tracks) in the cache 218. For example, in some embodiments, the life expectancy determination module 504 is configured to determine the amount of time that a non-preferred storage element 402b will reside in the cache 218 before being evicted. The life expectancy can be a number at a certain point in time or an average over a period of time. In some embodiments, the life expectancy is calculated by subtracting the timestamp of the least recently used non-preferred storage element 402b in the cache 218 from the timestamp of the most recently used non-preferred storage element 402b in the cache 218, where the timestamp indicates when the non-preferred storage element 402b was most recently accessed.

[0053] In contrast, residency determination module 506 may determine how long a particular storage element has been resident in cache 218. Residency time may be calculated, for example, by subtracting a timestamp of storage element 402 (which indicates when storage element 402 was last accessed) from a current time.

[0054] By using the expected lifetime calculated by the expected lifetime determination module 504 and the residency time calculated by the residency period determination module 506, the cache eviction module 508 can implement a cache eviction policy such that the preferred storage element 402 is retained in the cache 218 for a longer time than the expected lifetime of the non-preferred storage element 402b. For example, the cache eviction policy may require that the preferred storage element 402a be retained in the cache 218 for twice the expected lifetime of the non-preferred storage element 402b. Other multiples (i.e., numbers greater than 1, decimals, or fractions) are possible and are within the scope of the present invention. Example of method 600 that can be performed by the cache eviction module 508 in conjunction with Figure 6 Provide a description.

[0055] Figure 6One embodiment of a method 600 for evicting entries from a cache 218 to free up space in the cache 218 is shown. The method 600 is referenced previously in conjunction with Figure 4 4. A first set 404b of non-preferred storage elements 402b and a second set 404a of preferred storage elements 402a are depicted. In some embodiments, the first set 404b of non-preferred storage elements 402b is recorded in a first LRU (least recently used) list (i.e., a "non-preferred" LRU list), and the second set 404a of preferred storage elements 402a is recorded in a second LRU list (i.e., a "preferred" LRU list).

[0056] As shown, the method 600 initially determines 602 whether it is time to evict one or more storage elements 402 from the cache 218. In some embodiments, step 602 may involve determining whether the cache 218 is low on free space. If it is time to evict an entry from the cache 218, the method 600 determines 604 whether the "preferred" LRU list is empty. If so, the method 600 evicts 606 the oldest non-preferred storage element 402b (i.e., the non-preferred storage element 402b with the oldest timestamp) listed in the "non-preferred" LRU list from the cache 218. If the "preferred" LRU list is not empty, the method 600 determines 608 whether the "non-preferred" LRU list is empty. If so, the method 600 evicts 610 the oldest preferred storage element 402a listed in the "preferred" LRU list from the cache 218.

[0057] If both the "non-preferred" LRU list and the "preferred" LRU list are not empty, the method 600 determines 612 whether the oldest non-preferred storage element 402b in the "non-preferred" LRU list has a timestamp that is older than the oldest preferred storage element 402a in the "preferred" LRU list. If so, the method 600 evicts 614 the oldest non-preferred storage element 402b in the "non-preferred" LRU list from the cache 218. Otherwise, the method 600 proceeds to step 616. In step 616, the method 600 determines 616 whether the residency time of the oldest preferred storage element 402a in the cache 218 (i.e., the amount of time that the oldest preferred storage element 402a in the "preferred" LRU list has resided in the cache 218) is less than a multiple N multiplied by the expected lifetime of the non-preferred storage element 402b in the cache 218. If so, the method 600 evicts 618 the oldest non-preferred storage element 402b in the “non-preferred” LRU list from the cache 218. Conversely, if the residency time of the oldest preferred storage element 402a in the “preferred” LRU list is greater than N*(the expected lifetime of the non-preferred storage element 402b in the cache 218), the method 600 evicts 620 the oldest preferred storage element 402a in the “preferred” LRU list from the cache 218. The variable N is a residency multiplier, details of which will be explained in more detail below.

[0058] See also Figure 7 As previously described, the host system 102 may periodically send commands and / or lists to the storage system 110 to change or update which volumes 304 are considered preferred or non-preferred, and therefore which storage elements 402 are given cache priority. In some embodiments, the host system 102 periodically sends a command to the storage system 110 with a list 700 of volumes 304 that should be preferred. This list 700 of volumes 304 may change each time the host system 102 issues a command to the storage system 110. If a volume 304 was previously designated as preferred in the list 700 but is not designated as such in the new list 700, the storage system 110 may change the status of the volume 304 to non-preferred and stop providing cache priority to the volume 304.

[0059] In some embodiments, the host system 102 may set an indicator (e.g., a "FORCE FAVORED CACHE" indicator) for a particular volume 304 that indicates that the volume 304 will maintain its preferred status until the host system 102 affirmatively changes the volume status to non-preferred. The host system 102 may use a "REMOVE FAVORED CACHE" command to change the status of a volume 304 from preferred to non-preferred. In some embodiments, the "FORCE FAVORED CACHE" indicator may have a duration attached to it that indicates how long the volume 304 should remain in the preferred status before it returns to the non-preferred status. After the duration expires and the volume 304 is no longer included in the list 700, the status of the volume 304 may automatically become non-preferred so that it does not receive cache priority.

[0060] See also Figure 8 , because volume 304 can dynamically change from a preferred state to a non-preferred state and vice versa, Figure 6 Method 600 is modified differently to account for the fact that the state of the volume may have changed. This state change may warrant moving a storage element 402 from a "non-preferred" LRU list to a "preferred" LRU list or vice versa.

[0061] Figure 8 One embodiment of a method 800 for evicting an entry (ie, a storage element 402) from a cache 218 in order to free up space in the cache 218 is shown. Figure 6 The method 800 is similar to the method 600 shown in FIG, except that the method 800 has been modified to account for volumes 304 that may have changed from a preferred state to a non-preferred state, or vice versa. Figure 6 The same steps as in method 600 are shown with the same numbers, while new steps (ie, steps 802, 804, and 806) have been assigned new numbers. Figure 6 Compared to method 600 , the flow of method 800 is also slightly changed to take into account new steps 802 , 804 , and 806 .

[0062] like Figure 8 As shown, after determining 608 whether the "non-preferred" LRU list is empty, the method 800 can determine 802 whether the oldest entry in the "preferred" LRU list is no longer preferred. In other words, the method 800 can determine 802 whether the status of the oldest entry (i.e., storage element 402) in the "preferred" LRU list has changed from preferred to non-preferred. If so, the method 800 evicts 610 the oldest entry in the "preferred" LRU list from the cache 218.

[0063] Similarly, after decision step 616 has been executed, method 800 determines 806 whether the oldest entry in the "non-preferred" LRU list is now preferred. In other words, method 800 determines 806 whether the status of the oldest entry (i.e., storage element 402) in the "non-preferred" LRU list has changed from non-preferred to preferred. If so, method 800 transfers 804 the entry from the "non-preferred" LRU list to the most recently used end of the "preferred" LRU list, and method 800 then returns to step 612. If not, method 800 evicts 618 the oldest entry in the "non-preferred" LRU list from cache 218.

[0064] See also Figure 9 As previously described, the host system 102 may periodically send a command to the storage system 110 that includes the list 700 of which volumes 304 should be preferred. In some embodiments, the host system 102 may include a residency multiplier 902 along with the list 700 that indicates how strongly cache preference should be applied to the preferred volume 304a. The higher the residency multiplier 902, the stronger the cache preference, and thus the longer the preferred volume 304a remains in the cache 218 relative to the non-preferred volumes 304b. The lower the residency multiplier 902, the weaker the cache preference, and thus the shorter the time the preferred volume 304a remains in the cache 218 relative to the non-preferred volumes 304b. In some embodiments, a single residency multiplier 902 is provided for all preferred volumes 304a in the list 700. In other embodiments, different residency multipliers 902 are provided for different preferred volumes 304a, such as those that would be combined. Figure 10 and 11 As explained in more detail.

[0065] A priority adjustment module 900 can be provided on the host system 102 or another system to determine which volumes 304 should be considered preferred volumes 304a and to determine a residency multiplier 902 for each preferred volume 304a. Generally, the priority adjustment module 900 can track I / O to the volumes 304 on the storage system 110 and, based on this tracking information, determine which volumes 304 should be considered preferred. Using the tracking information, the priority adjustment module 900 can also determine how strong a cache preference should be for the preferred volumes 304a, either individually or collectively.

[0066] See also Figure 10, a high-level block diagram showing the priority adjustment module 900 and associated sub-modules is shown. The priority adjustment module 900 and associated sub-modules can be implemented in hardware, software, firmware, or a combination thereof. The priority adjustment module 900 and associated sub-modules are presented as examples and not limitations. In different embodiments, more or fewer sub-modules may be provided. For example, the functionality of some sub-modules may be combined into a single or smaller number of sub-modules, or the functionality of a single sub-module may be distributed across several sub-modules. Although the priority adjustment module 900 and associated sub-modules are shown within the host system 102, all functionality need not be implemented within the host system 102, nor is it limited to implementation within the host system 102. Thus, the location of the priority adjustment module 900 and associated sub-modules is provided as an example and not a limitation.

[0067] As shown, the priority adjustment module 900 includes one or more of an I / O tracking module 1000 , a volume ranking module 1010 , a list creation module 1012 , a residency determination module 1014 , a multiplier calculation module 1016 , and a transmission module 1018 .

[0068] The I / O tracking module 1000 can be configured to track I / O issued from the host system 102 to the storage system 110. This I / O can indicate which volumes 304 should be prioritized and accessed via the faster synchronous I / O process. For example, a higher volume of I / O to volume 304 can indicate that a job is running against volume 304 and that the job can be executed faster and more efficiently using synchronous I / O. In this case, volume 304 can be given cache priority so that more of its data remains in cache 218 for a longer period of time, thereby ensuring a higher cache hit rate when accessing volume 304.

[0069] When tracking I / O to volume 304, I / O tracking module 1000 can distinguish between different types of I / O. For example, I / O tracking module 1000 can track transactional reads 1002, transactional writes 1004, transactional reads 1006, and transactional writes 1008. In some embodiments, I / O tracking module 1000 can utilize counters to track the amount of each of these different types of I / O to volume 304.

[0070] Using the information collected by the I / O tracking module 1000, the volume ranking module 1010 can rank the volumes 304 on the storage system 110. For example, the volume ranking module 1010 can rank each volume 304 using the formula A*L+B*M+C*P+D*Q, where A is the number of read accesses to the volume 304 within a transaction, B is the number of write accesses to the volume 304 within a transaction, C is the number of read accesses to the volume 304 outside a transaction, and D is the number of write accesses to the volume 304 outside a transaction. L, M, P, and Q are weight coefficients (e.g., L=4, M=3, P=2, Q=1), where L>M>P>Q. In other words, for the purpose of establishing cache priority, accesses to the volume 304 within a transaction can be weighted more heavily than accesses to the volume 304 outside a transaction. Furthermore, for the purpose of establishing cache priority, reads to the volume 304 can be weighted more heavily than writes to the volume 304.

[0071] Using the output of the above calculations for each volume 304, the volume ranking module 1010 can rank the volumes 304 on the storage system 110 by the magnitude of the output value of the volume 304. Generally speaking, volumes 304 with a greater amount of I / O can have a greater output value and, therefore, be ranked higher than volumes 304 with a lower amount of I / O during the same time period. The list creation module 1012 can then create a list 700 of volumes 304 that should be prioritized and provided with cache priority. This can include a specific number of the highest-ranked volumes 304, volumes 304 with output values ​​above a specific threshold, etc.

[0072] The residency determination module 1014 can determine the residency time (i.e., life expectancy) of the storage elements 402 of the non-preferred volume 304b within the cache 218. The multiplier calculation module 1016 can then determine the residency multiplier 902 for the preferred volume 304a. For example, if the storage elements 402 of the preferred volume 304a will reside in the cache 218 for twice the amount of time as the storage elements 402 of the non-preferred volume 304b, the residency multiplier 902 can be set to two. In some embodiments, the residency multiplier 902 is determined by taking the above-described output value from the preferred volume 304a and dividing it by the output value from the non-preferred volume 304b to produce a ratio. If desired, the residency multiplier 902 can be floored so that it does not fall below a certain value (e.g., two) regardless of the ratio. This will ensure that the storage elements 402 of the preferred volume 304a are retained in the cache 218 for at least twice the amount of time as the storage elements 402 of the non-preferred volume 304b.

[0073] Once the list 700 has been created and the residency multiplier 902 has been determined, the transfer module 1018 can transfer the list 700 and the residency multiplier 902 from the host system 102 to the storage system 110. As previously explained, in some embodiments, a single residency multiplier 902 can be calculated for all preferred volumes 304a in the list 700. In other embodiments, a different residency multiplier 902 (N) can be calculated for each preferred volume 304a in the list 700, such as Figure 11 As shown in . Figure 11 As shown, the list 700 records the document volumes 304 to be preferred in ranking order (i.e., in the order of their output values ​​using the above calculations). Each preferred volume 304a has a different residency multiplier 902 associated with it. The higher the ranking of the volume 304, the greater the residency multiplier 902. As previously described, the residency multiplier 902 can be multiplied by the expected lifespan of the storage elements 402 of the non-preferred volumes 304b to determine the amount of time that the storage elements 402 of the preferred volume 304a should be retained in the cache 218.

[0074] See also Figure 12 In some embodiments, the preferred volumes 304a in the list 700 may share the same residency multiplier 902 and, therefore, have the same preferred cache residency time. For example, a first preferred volume set 304a (i.e., volumes A, B, and C) may be assigned a first residency multiplier N1, a second preferred volume set 304a (i.e., volumes D and E) may be assigned a second residency multiplier N2, and a third preferred volume set 304a (i.e., volumes F and G) may be assigned a third residency multiplier N3, where N1 > N2 > N3. Each residency multiplier 902 indicates how strong the cache preference (i.e., preferred cache residency time) of its corresponding set of preferred volumes 304a should be. In some embodiments, in a storage system 110 such as the IBM DS8000™ Enterprise Storage System 110, the residency multiplier 902 for each volume 304 is stored in a global state area (e.g., an area in the cache 218 that is mirrored to the more persistent storage drives 204) so ​​that the residency multiplier 902 is not lost during a reboot, power loss, failure, etc.

[0075] See also Figure 13In some embodiments, an LRU list 1300 is created for each residency multiplier 902 and an associated set of preferred volumes 304a. An LRU list 1300d may also be created for all non-preferred volumes 304b (i.e., volumes 304 that do not have a residency multiplier 902 or have a residency multiplier 902 of 1). When an unmodified storage element 402 (e.g., an unmodified track) is added to the cache 218, the volume 304 associated with the storage element 402 may be checked to determine whether it is a preferred volume 304a, and if so, what the residency multiplier 902 of the volume 304 is. Based on the residency multiplier 902 of the volume 304 (or the absence of a residency multiplier), the entry associated with the unmodified storage element 402 may be added to the most recently used (MRU) end of the appropriate LRU list 1300. If an LRU list 1300 for the residency multiplier 902 associated with the volume 304 does not exist, an LRU list 1300 may be created for the residency multiplier 902 , and entries associated with the unmodified storage element 402 may be added to the newly created LRU list 1300 .

[0076] Figure 14 shows the use of Figure 13 1300 from the cache 218. As shown, the method 1400 initially determines 1402 whether it is time to evict one or more storage elements 402 from the cache 218. In some embodiments, this step 1402 may involve determining whether the cache 218 is low on free space. If it is time to evict an entry from the cache 218 (e.g., the cache 218 is low on free space), the method 1400 determines 1404 whether the LRU list 1300 associated with the preferred volume 304a (hereinafter referred to as the "preferred" LRU list 1300) is completely empty. If so, the method 1400 evicts 1406 from the cache 218 the storage element 402 associated with the oldest entry (i.e., the entry at the LRU end of the LRU list) in the LRU list 1300 for the non-preferred volume 304b (hereinafter referred to as the "non-preferred" LRU list 1300).

[0077] On the other hand, if the "preferred" LRU list 1300 is not entirely empty, the method 1400 calculates 1410 the "time above required residency" for the non-empty "preferred" LRU list 1300. In some embodiments, the "time above required residency" can be calculated by determining the residency time of the oldest entry in the "preferred" LRU list 1300 and subtracting from that value the "expected lifetime" multiplied by the residency multiplier 902. As previously explained, the "expected lifetime" can be equal to the amount of time that the non-preferred storage element 402b will reside in the cache 218 before being evicted. Generally, step 1410 determines the amount that the oldest entry in the "preferred" LRU list 1300 has exceeded (or fallen short of) its preferred residency time in the cache 218.

[0078] Then, the method 1400 selects 1412 the "preferred" LRU list 1300 whose oldest entry has the largest "time above required residency time." The method 1400 then determines 1414 whether this "time above required residency time" is negative (meaning that the storage element associated with the oldest entry in the "preferred" LRU list 1300 has been resident in the cache 218 for some amount of time that is less than its preferred residency time). If the "time above required residency time" is negative, the method 1400 determines 1416 whether the "non-preferred" LRU list 1300 is empty. If it is not empty, the method 1400 evicts 1406 the storage element 402 associated with the oldest entry in the "non-preferred" LRU list 1300 from the cache 218.

[0079] If, at step 1414, the "time above required residency" is not negative (meaning that the oldest entry in the "preferred" LRU list 1300 has been resident in the cache 218 for some amount of time greater than or equal to its preferred residency), then the method 1400 evicts 1408 from the cache 218 the storage element associated with the oldest entry in the "preferred" LRU list 1300 with the largest "time above required residency." Similarly, if, at step 1416, the "non-preferred" LRU list 1300 is found to be empty, then the method 1400 also evicts 1408 from the cache 218 the oldest entry in the "preferred" LRU list 1300 with the largest "time above required residency."

[0080] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions, and operations of possible implementations of systems, methods, and computer program products according to different embodiments of the present invention. In this regard, each box in the flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative embodiments, the functions indicated in the box may not occur in the order indicated in the figure. For example, depending on the functions involved, two boxes shown in succession may actually be executed substantially simultaneously, or the boxes may sometimes be executed in the opposite order. Other implementations may not require all disclosed steps to achieve the desired function. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs a specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

Claims

1. A method for improving a cache hit rate of a selected volume when using synchronous I / O, the method comprising: establishing a first set of non-preferred storage elements from a non-preferred storage region in a cache; establishing a second set of preferred storage elements from a preferred storage region in the cache; calculating an expected lifetime of the non-preferred storage element residing in the cache; multiplying the expected lifetime by a residency multiplier to determine an amount of time the preferred storage element will reside in the cache; Recording the first set of non-preferred storage elements in a first least recently used (LRU) list and recording the second set of preferred storage elements in a second LRU list; eviction of the oldest preferred storage element in the second LRU list from the cache in response to a residency time of the oldest preferred storage element in the second LRU list being greater than or equal to an amount of time the preferred storage element will reside in the cache; eviction of an oldest non-preferred storage element in the first LRU list from the cache in response to a residency time of an oldest preferred storage element in the second LRU list being less than an amount of time the preferred storage element will reside in the cache; Accessing the preferred storage element via a synchronous I / O process; and The non-preferred storage element is accessed through an asynchronous I / O process.

2. The method according to claim 1, wherein The residency multiplier is calculated by dividing the output value associated with the preferred storage region by the output value associated with the non-preferred storage region.

3. The method according to claim 1, wherein The non-preferred storage area is a non-preferred volume, and the preferred storage area is a preferred volume.

4. The method according to claim 1, wherein The preferred storage element is maintained in the cache for at least some multiple of an expected lifetime of the non-preferred storage element in the cache.

5. The method according to claim 1, wherein Calculating the expected lifetime includes subtracting a timestamp of a least recently used non-preferred storage element in the first set from a timestamp of a most recently used non-preferred storage element in the first set.

6. The method according to claim 1, further comprising: When a storage element transitions between a preferred state and a non-preferred state, the storage element is moved between the first LRU list and the second LRU list.

7. The method according to claim 1, wherein The non-preferred storage area and / or the preferred storage area are established using at least one of an online command and a configuration file.

8. A computer program product for improving a cache hit rate of a selected volume when using synchronous I / O, the computer program product comprising a non-transitory computer-readable storage medium having computer-usable program code embodied therein, the computer-usable program code being configured to, when executed by at least one processor, perform the following operations: establishing a first set of non-preferred storage elements from a non-preferred storage region in a cache; establishing a second set of preferred storage elements from a preferred storage region in the cache; calculating an expected lifetime of the non-preferred storage element residing in the cache; multiplying the expected lifetime by a residency multiplier to determine an amount of time the preferred storage element will reside in the cache; Recording the first set of non-preferred storage elements in a first least recently used (LRU) list and recording the second set of preferred storage elements in a second LRU list; eviction of the oldest preferred storage element in the second LRU list from the cache in response to a residency time of the oldest preferred storage element in the second LRU list being greater than or equal to an amount of time the preferred storage element will reside in the cache; eviction of an oldest non-preferred storage element in the first LRU list from the cache in response to a residency time of an oldest preferred storage element in the second LRU list being less than an amount of time the preferred storage element will reside in the cache; Accessing the preferred storage element via a synchronous I / O process; and The non-preferred storage element is accessed through an asynchronous I / O process.

9. The computer program product according to claim 8, wherein: The residency multiplier is calculated by dividing the output value associated with the preferred storage region by the output value associated with the non-preferred storage region.

10. The computer program product of claim 8, wherein: The non-preferred storage area is a non-preferred volume, and the preferred storage area is a preferred volume.

11. The computer program product of claim 8, wherein: The preferred storage element is maintained in the cache for at least some multiple of an expected lifetime of the non-preferred storage element in the cache.

12. The computer program product of claim 8, wherein: Calculating the expected lifetime includes subtracting a timestamp of a least recently used non-preferred storage element in the first set from a timestamp of a most recently used non-preferred storage element in the first set.

13. The computer program product of claim 8, wherein: The computer usable program code is further configured to: When a storage element transitions between a preferred state and a non-preferred state, the storage element is moved between the first LRU list and the second LRU list.

14. The computer program product of claim 8, wherein: The non-preferred storage area and / or the preferred storage area are established using at least one of an online command and a configuration file.

15. A system for improving cache hit rate of a selected volume when using synchronous I / O, the system comprising: at least one processor; at least one memory device operatively coupled to the at least one processor and storing instructions for execution on the at least one processor, the instructions causing the at least one processor to: establishing a first set of non-preferred storage elements from a non-preferred storage region in a cache; establishing a second set of preferred storage elements from a preferred storage region in the cache; calculating an expected lifetime of the non-preferred storage element residing in the cache; and multiplying the expected lifetime by a residency multiplier to determine an amount of time the preferred storage element will reside in the cache; Recording the first set of non-preferred storage elements in a first least recently used (LRU) list and recording the second set of preferred storage elements in a second LRU list; eviction of the oldest preferred storage element in the second LRU list from the cache in response to a residency time of the oldest preferred storage element in the second LRU list being greater than or equal to an amount of time the preferred storage element will reside in the cache; eviction of an oldest non-preferred storage element in the first LRU list from the cache in response to a residency time of an oldest preferred storage element in the second LRU list being less than an amount of time the preferred storage element will reside in the cache; Accessing the preferred storage element via a synchronous I / O process; and The non-preferred storage element is accessed through an asynchronous I / O process.

16. The system according to claim 15, wherein: The residency multiplier is calculated by dividing the output value associated with the preferred storage region by the output value associated with the non-preferred storage region.

17. The system according to claim 15, wherein: The non-preferred storage area is a non-preferred volume, and the preferred storage area is a preferred volume.

18. The system according to claim 15, wherein: The preferred storage element is maintained in the cache for at least some multiple of an expected lifetime of the non-preferred storage element in the cache.

19. The system of claim 15, wherein: Calculating the expected lifetime includes subtracting a timestamp of a least recently used non-preferred storage element in the first set from a timestamp of a most recently used non-preferred storage element in the first set.

20. The system of claim 15, further comprising: When a storage element transitions between a preferred state and a non-preferred state, the storage element is moved between the first LRU list and the second LRU list.

Images