Managing caching of extents of tracks in a first cache, second cache and storage

Provided are a computer program product, system, and method for managing caching of extents of tracks in a first cache, second cache and storage device. A determination is made of an eligible track in a first cache eligible for demotion to a second cache, wherein the tracks are stored in extents configured in a storage device, wherein each extent is comprised of a plurality of tracks. A determination is made of an extent including the eligible track and whether second cache caching for the determined extent is enabled or disabled. The eligible track is demoted from the first cache to the second cache in response to determining that the second cache caching for the determined extent is enabled. Selection is made not to demote the eligible track in response to determining that the second cache caching for the determined extent is disabled.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a computer program product, system, and method for managing caching of extents of tracks in a first cache, second cache and storage.

2. Description of the Related Art

A cache management system buffers tracks in a storage device recently accessed as a result of read and write operations in a faster access storage device, such as memory, than the storage device storing the requested tracks. Subsequent read requests to tracks in the faster access cache memory are returned at a faster rate than returning the requested tracks from the slower access storage, thus reducing read latency. The cache management system may also return complete to a write request when the modified track directed to the storage device is written to the cache memory and before the modified track is written out to the storage device, such as a hard disk drive. The write latency to the storage device is typically significantly longer than the latency to write to a cache memory. Thus, using cache also reduces write latency.

A cache management system may maintain a linked list having one entry for each track stored in the cache, which may comprise write data buffered in cache before writing to the storage device or read data. In the commonly used Least Recently Used (LRU) cache technique, if a track in the cache is accessed, i.e., a cache “hit”, then the entry in the LRU list for the accessed track is moved to a Most Recently Used (MRU) end of the list. If the requested track is not in the cache, i.e., a cache miss, then the track in the cache whose entry is at the LRU end of the list may be removed (or destaged back to storage) and an entry for the track data staged into cache from the storage is added to the MRU end of the LRU list. With this LRU cache technique, tracks that are more frequently accessed are likely to remain in cache, while data less frequently accessed will more likely be removed from the LRU end of the list to make room in cache for newly accessed tracks.

The Easy Tier application offered by International Business Machines Corporation (“IBM”) migrates extents of frequently accessed data from hard disk drive storage to a solid state storage device (SSD), which has faster access than the disk drives. The Easy Tier application monitors Input/Output (I/O) workload to extents of tracks, and if the workload or activity with respect to the extent reaches a certain threshold, then the Easy Tier application migrates the extent to the SSD where access times are improved. In this way, “hot extents”, those frequently accessed, are migrated to the SSD, while “cold extents”, those deemed less frequently accessed, are migrated from the SSD to the hard disk drives.

There is a need in the art for improved techniques for using cache in a storage system.

SUMMARY

Provided are a computer program product, system, and method for managing caching of extents of tracks in a first cache, second cache and storage device. A determination is made of an eligible track in a first cache eligible for demotion to a second cache, wherein the tracks are stored in extents configured in a storage device, wherein each extent is comprised of a plurality of tracks. A determination is made of an extent including the eligible track and whether second cache caching for the determined extent is enabled or disabled. The eligible track is demoted from the first cache to the second cache in response to determining that the second cache caching for the determined extent is enabled. Selection is made not to demote the eligible track in response to determining that the second cache caching for the determined extent is disabled.

DETAILED DESCRIPTION

Described embodiments provide techniques to manage the migration of extents of tracks in a storage device to a second cache that provides a secondary cache to a first cache, where host read and write activity is directed to the first cache. The second cache stores tracks being transferred between the first cache and the storage device, where the first cache may comprise a faster access device than the second cache and the second cache may comprise a faster access device than the storage device. With described embodiments, tracks are demoted from the first cache to the second cache if second cache caching is enabled for the extent. The second cache caching for an extent in the second cache is disabled if an activity level of destage and stage operations for the extent exceed an activity threshold and if a distribution of the tracks in the extent subject to destage and stage operations exceeds a distribution threshold. This prevents the first cache from demoting an eligible track to the second cache that is in an extent already in the second cache that has a relatively high amount of activity and distribution of activity. Caching to the tracks in the extent in the second cache may be enabled after a predetermined time or after the extent is migrated from the second cache back to the storage.

FIG. 1illustrates an embodiment of a computing environment. A plurality of hosts2a,2b. . .2nmay submit Input/Output (I/O) requests to a storage controller4over a network6to access data at volumes8(e.g., Logical Unit Numbers, Logical Devices, Logical Subsystems, etc.) in a storage10. The storage controller4includes a processor complex12, including one or more processors with single or multiple cores, a first cache14, a first cache backup device16, to backup tracks in the cache14, and a second cache18. The first14and second18caches cache data transferred between the hosts2a,2b. . .2nand the storage10. The first cache backup device16may provide non-volatile storage of tracks in the first cache14. In a further embodiment, the first cache backup device16may be located in a cluster or hardware on a different power boundary than that of the first cache14.

The storage controller4has a memory20that includes a storage manager22for managing the transfer of tracks transferred between the hosts2a,2b. . .2nand the storage10and a cache manager24that manages data transferred between the hosts2a,2b. . .2nand the storage10in the first cache14, first cache backup device16, and the second cache18. A track may comprise any unit of data configured in the storage10, such as a track, Logical Block Address (LBA), etc., which is part of a larger grouping of tracks, such as a volume, logical device, etc. The cache manager24maintains first cache management information26and second cache management information28to manage read (unmodified) and write (modified) tracks in the first cache14and the second cache18. A first cache backup device index30provides an index of track identifiers to a location in the first cache backup device16.

The storage manager22may configure extents in the storage10, where each extent is assigned a plurality of tracks in the storage10. In this way, the storage10manages tracks in groups of extents, whereas the cache manager24manages tracks in the first14and second18caches.

The second cache18may store tracks in a log structured array (LSA)32, where tracks are written in a sequential order as received, thus providing a temporal ordering of the tracks written to the second cache18. In a LSA, later versions of tracks already present in the LSA are written at the end of the LSA32. In alternative embodiments, the second cache18may store data in formats other than in an LSA.

The storage controller4may further include a migration manager34that manages the migration of extents between the storage10and the second cache18. In certain embodiments, the migration manager34may migrate extents in the storage10to the second cache18that have a high level of activity, such as a high level of being subject to destage and stage operations. The migration manager34may be part of the storage manager22or a separate program.

The storage manager22, cache manager24, and migration manager34are shown inFIG. 1as program code loaded into the memory20and executed by the processor complex12. Alternatively, some or all of the functions may be implemented in hardware devices in the storage controller4, such as in Application Specific Integrated Circuits (ASICs).

In one embodiment, the first cache14may comprise a Random Access Memory (RAM), such as a Dynamic Random Access Memory (DRAM), and the second cache18may comprise a flash memory, such as a solid state device, and the storage10is comprised of one or more sequential access storage devices, such as hard disk drives and magnetic tape. The storage10may comprise a single sequential access storage device or may comprise an array of storage devices, such as a Just a Bunch of Disks (JBOD), Direct Access Storage Device (DASD), Redundant Array of Independent Disks (RAID) array, virtualization device, etc. In one embodiment, the first cache14is a faster access device than the second cache18, and the second cache18is a faster access device than the storage10. Further, the first cache14may have a greater cost per unit of storage than the second cache18and the second cache18may have a greater cost per unit of storage than storage devices in the storage10.

The first cache14may be part of the memory20or implemented in a separate memory device, such as a DRAM. In one embodiment, the first cache backup device16may comprise a non-volatile backup storage (NVS), such as a non-volatile memory, e.g., battery backed-up Random Access Memory (RAM), static RAM (SRAM), etc.

The network6may comprise a Storage Area Network (SAN), a Local Area Network (LAN), a Wide Area Network (WAN), the Internet, and Intranet, etc.

FIG. 2illustrates an embodiment of the first cache management information26including a track index50providing an index of tracks in the first cache14to control blocks in a control block directory52; an unmodified sequential LRU list54providing a temporal ordering of unmodified sequential tracks in the first cache14; a modified LRU list56providing a temporal ordering of modified sequential and non-sequential tracks in the first cache14; and an unmodified non-sequential LRU list58providing a temporal ordering of unmodified non-sequential tracks in the first cache14.

In certain embodiments, upon determining that the first cache backup device16is full, the modified LRU list56is used to destage modified tracks from the first cache14so that the copy of those tracks in the first cache backup device16may be discarded to make room in the first cache backup device16for new modified tracks.

FIG. 3illustrates an embodiment of the second cache management information28including a track index70providing an index of tracks in the second cache18to control blocks in a control block directory72; an unmodified list74providing a temporal ordering of unmodified tracks in the second cache18; a spatial index76providing a spatial ordering of the modified tracks in the second cache18based on the physical locations in the storage10at which the modified tracks are stored; extent caching information80providing information on extents in the second cache18that have been migrated from the storage10; and extent activity80providing information on read/stage and write/destage activity with respect to extents in the second cache18or the storage10.

All the LRU lists54,56,58, and74may include the track IDs of tracks in the first cache14and the second cache18ordered according to when the identified track was last accessed. The LRU lists54,56,58, and74have a most recently used (MRU) end indicating a most recently accessed track and a LRU end indicating a least recently used or accessed track. The track IDs of tracks added to the caches14and18are added to the MRU end of the LRU list and tracks demoted from the caches14and18are accessed from the LRU end. The track indexes50and70and spatial index76may comprise a scatter index table (SIT). Alternative type data structures may be used to provide the temporal ordering of tracks in the caches14and18and spatial ordering of tracks in the second cache18.

Non-sequential tracks may comprise Online Line Transaction Processing (OLTP) tracks, which often comprise small block writes that are not fully random and have some locality of reference, i.e., have a probability of being repeatedly accessed.

FIG. 4illustrates an embodiment of a first cache control block100entry in the control block directory52, including a control block identifier (ID)102, a first cache location104of the physical location of the track in the first cache14, information106indicating whether the track is modified or unmodified, and information108indicating whether the track is a sequential or non-sequential access.

FIG. 5illustrates an embodiment of a second cache control block120entry in the second cache control block directory72, including a control block identifier (ID)122, an LSA location124where the track is located in the LSA32, and information126indicating whether the track is modified or unmodified.

FIG. 6illustrates a spatial index entry140including a track identifier142of a track in the second cache18and the physical location144of where the track is stored in the storage10, such as a cylinder, platter, block address, and storage device identifier.

FIG. 7illustrates an embodiment of an instance of extent caching information entry150included in the extent caching information78for each extent in the second cache18indicating an extent identifier (ID)152of the extent and a second cache caching setting154indicating whether second cache caching is enabled or disabled for the extent152in the second cache18. If second cache caching154is disabled for an extent152in the second cache18, then tracks in that extent152cannot be demoted form the first cache14to the second cache18. Further, if second cache caching154is disabled, then tracks in the extent152in the second18cache may not be eligible for demotion from the second cache18to the storage10.

FIG. 8illustrates an embodiment of an extent activity entry160included in the extent activity80information for each extent indicating an extent identifier (ID)162of the extent, a destage/write activity164and stage/read activity166indicating a number of destage/writes and stage/reads, respectively, to tracks in the extent while in the storage10or the second cache18; and an activity distribution168indicating a distribution of the destage/stage activity with respect to different tracks of the extent. This distribution value168may indicate a number or proportion of tracks subject to activity, a standard deviation of tracks subject to activity, or some other indicator of the number of tracks participating in the destage/stage activity.

In one embodiment, the extent activity164and166may indicate the number of times a track in an extent located in the storage10or second cache18is written/destaged or read/staged from the first cache14. The activity may not reflect the number of times the track is read or written while in the first cache14, only the activity with respect to moving an extent track from the first cache14to the second cache18or storage10.

FIG. 9illustrates an embodiment of operations performed by the cache manager24to demote unmodified tracks from the first cache14. The demote operation may be initiated upon determining to free space in the first cache14. Upon initiating (at block200) an operation to determine whether to remove tracks from the first cache14to free space in the first cache14, the cache manager24determines (at block202) whether to demote non-sequential or sequential unmodified tracks based on expected hits to different types of unmodified tracks. If (at block204) the determination is to demote unmodified sequential tracks, then the cache manager24uses (at block206) the unmodified sequential LRU list54to determine unmodified sequential tracks to demote, from the LRU end of the list, which are not promoted to the second cache18. If (at block204) the determination is made to demote unmodified non-sequential tracks, then the cache manager uses the unmodified non-sequential LRU list58to determine (at block208) unmodified non-sequential tracks to demote. The unmodified non-sequential tracks are promoted (at block210) to the second cache18.

FIG. 10illustrates an embodiment of operations performed by the cache manager24to destage modified tracks from the first cache14. The cache manager24may regularly destage tracks as part of scheduled operations and increase the rate of destages if space is needed in the first cache backup device16. Upon initiating (at block250) the operation to destage modified tracks, the cache manager24processes (at bock252) the modified LRU list56to determine modified tracks to destage, from the LRU end of the LRU list56. If (at block254) the determined modified tracks are sequential, then the cache manager24writes (at block256) the determined modified sequential tracks to the storage10, bypassing the second cache18. If (at block254) the modified tracks are non-sequential, then the cache manager24promotes (at block258) the determined modified non-sequential tracks to the second cache18and discards (at block260) the copy of the determined modified tracks from the first cache backup device16.

With the operations ofFIGS. 9 and 10, non-sequential tracks are demoted but not promoted to the second cache18. Sequential modified (writes) are written directly to the storage10, bypassing the second cache. Sequential unmodified tracks (reads) are discarded and not copied elsewhere, and unmodified non-sequential tracks demoted from the first cache14are promoted to the second cache18.

FIG. 11illustrates an embodiment of operations performed by the cache manager24to add, i.e., promote, a track to the first cache14, which track may comprise a write or modified track from a host2a,2b. . .2n, a non-sequential track in the second cache18that is subject to a read request and as a result moved to the first cache14, or read requested data not found in either cache14or18and retrieved from the storage10. Upon receiving (at block300) the track to add to the first cache14, the cache manager24creates (at block301) a control block100(FIG. 4) for the track to add indicating the104location in the first cache14and whether the track is modified/unmodified106and sequential/non-sequential108. This control block100is added to the control block directory52of the first cache14. The cache manager24adds (at block302) an entry to the first cache track index50having the track ID of track to add and an index to the created cache control block100in the control block directory52. An entry is added (at block304) to the MRU end of the LRU list54,56or58of the track type of the track to add. If (at block306) the track to add is a modified non-sequential track, then the track to add is also copied (at block308) to the first cache backup device16and an entry is added to the first cache backup device index30for the added track. If (at block306) the track to add is unmodified sequential, control ends.

FIG. 12illustrates an embodiment of operations performed by the cache manager24to promote non-sequential tracks to the second cache18that are being demoted from the first cache14. Upon initiating (at block350) the operation to promote a track to the second cache18, the cache manager24adds (at block352) the track being promoted to the LSA32in the second cache18and creates (at block354) a control block120(FIG. 5) for the track to add indicating the track location124in the LSA32and whether the track is modified/unmodified126. An entry is added (at block356) to the second cache track index70having the track ID of the promoted track and an index to the created cache control block120in the control block directory72for the second cache18. If (from the no branch of block358) the track being promoted is unmodified data, then the cache manager24indicates (at block360) the promoted track at the MRU end of the unmodified LRU list74, such as by adding the track ID to the MRU end. If (at block358) the promoted track is modified data, then the cache manager24determines (at block362) a physical location of the where to write the modified promoted track on the storage10and adds (at block364) an entry to the spatial index76indicating the track ID142of the promoted track and the determined physical location144of the promoted track on the storage10.

FIG. 13illustrates an embodiment of operations performed by the cache manager24to free space in the second cache18for new tracks to add to the second cache18, i.e., tracks being demoted from the first cache14or promoted from the storage10. Upon initiating this operation (at block400) the cache manager24determines (at block402) unmodified tracks in the second cache18from the LRU end of the unmodified LRU list74and invalidates (at block404) the determined unmodified tracks without destaging the invalidated unmodified tracks to the storage10, and also removes the invalidated unmodified tracks from the unmodified LRU list74.

FIG. 14illustrates an embodiment of operations performed by the cache manager24to destage modified tracks in the second cache12to the storage10. Upon initiating (at block420) the destage operation, the cache manager24uses (at block422) the spatial index76to determine modified tracks in the second cache18to group that are at proximate physical locations on the storage device based on their order in the spatial index76, such as a group of tracks at consecutive entries140(FIG. 6) in the location ordered spatial index76. The determined grouped modified tracks are destaged (at block424) from the second cache18to the storage device10.

The operations ofFIG. 14optimize write operations to the storage10, which comprises a sequential access storage device, by having the storage10write tracks at physical locations at closest physical proximity on the storage10writing surface, thus minimizing the amount of seeking and movement of the storage10write head to write the tracks in the second cache18to storage10. The tracks were promoted to the second cache18from the from the first cache16based on temporal factors, such as their position in an LRU list54,56,58, and not in an order optimized for sequential writing to a sequential access storage10, such as a hard disk drive. Thus, the operations ofFIG. 12optimize the temporally ordered modified tracks based on their spatial location on the storage10to optimize writing at the storage10.

FIG. 15illustrates an embodiment of operations performed by the cache manager24to retrieve requested tracks for a read request from the caches14and18and storage10. The storage manager22processing the read request may submit requests to the cache manager24for the requested tracks. Upon receiving (at block450) the request for the tracks, the cache manager24uses (at block454) the first cache track index50to determine whether all of the requested tracks are in the first cache14. If (at block454) all requested tracks are not in the first cache14, then the cache manager24uses (at block456) the second cache track index70to determine any of the requested tracks in the second cache18not in the first cache14. If (at block458) there are any requested tracks not found in the first14and second18caches, then the cache manager24determines (at block460) any of the requested tracks in the storage10, from the second cache track index70, not in the first14and the second18caches. The cache manager24then promotes (at block462) any of the determined tracks in the second cache18and the storage10to the first cache14. The cache manager24uses (at block464) the first cache track index50to retrieve the requested tracks from the first cache14to return to the read request. The entries for the retrieved tracks are moved (at block466) to the MRU end of the LRU list54,56,58including entries for the retrieved tracks.

With the operations ofFIG. 15, the cache manager24retrieves requested tracks from a highest level cache14, then second cache18first before going to the storage10, because the caches14and18would have the most recent modified version of a requested track. The most recent version is first found in the first cache14, then the second cache18if not in the first cache14and then the storage10if not in either cache14,18.

FIG. 16illustrates an embodiment of operations performed by the cache manager24or other component, such as the storage manager22or migration manager34, to maintain the extent activity82information. Upon detecting (at block500) an operation that destages or stages data with respect to a track in an extent in the storage10or the second cache18, the cache manager24updates (at block502) the destage/write164or stage/read166activity information for the extent162to reflect the additional activity. The cache manager24may further update the activity distribution168information to indicate update a number of the tracks in the extent that have been subject to the stage or destage operation. The distribution168information indicates the number of tracks of an extent involved in the activity.

In the operations ofFIG. 16, the cache manager24tracks destage and stage activity when the track is destaged or staged between the first cache14and the second cache18, destaged or staged between the first cache14and the storage10, destaged or staged between the second cache18and the storage10, regardless of how many times the track is modified or read while in the first cache14and second cache18. For instance, a tracked destage/stage activity resulting in the update of the extent activity information164,166,168may comprise the promotion/demotion of a track from the first cache14to the second cache18at blocks206and210inFIG. 9and block258inFIG. 10; the destaging of a track from the first cache14to the storage10at block256inFIG. 10; the promotion or staging for a track from the storage10or second cache18to the first cache14at block300inFIG. 11; the promotion/destaging of a track from the first cache14to the second cache18at block350inFIG. 12; the destaging of modified tracks in the second cache18to the storage10inFIG. 14; and the staging/promotion of tracks in the second cache18or storage10to the first cache14at block462inFIG. 15.

FIG. 17illustrates an embodiment of operations performed by the migration manager34to migrate an extent from the storage10to a faster access second cache18. Upon (at block520) initiating an operation to determine whether to migrate an extent in the storage10, the migration manager34determines (at block522) activity (stage164and/or destage166activity) at the extent in the storage device10. The migration manager34determines (at block524) whether determined activity (such as total stage/read164and destage/write166activity) exceeds a threshold level of activity, such as a threshold number of stage and destage operations. The measured values and threshold may comprise different measurements, such as a number of measurements over a time period. If (at block524) the threshold level of activity is not satisfied, then control ends. Otherwise, if the threshold is met, then the migration manager34determines (at block526) a distribution168of the tracks in the extents subject to destage and stage operations in the storage device, i.e., the proportion, number of tracks, etc., participating in the activity. If (at block528) the determined distribution of activity does not exceed a threshold distribution value, then control ends. Otherwise, if (at block528) the distribution level threshold is satisfied, then the migration manager34migrates (at block530) the extent from the storage device10to the second cache18and indicates (at block532) the second cache caching154for the extent152as disabled, so that tracks in the extent will not promoted to or demoted from the second cache18.

In the described embodiments ofFIG. 17, the migration manager34checks both the amount of activity and distribution of activity. In alternative embodiments, the migration manager34may check the threshold with either the magnitude of activity or the distribution.

FIG. 18illustrates an embodiment of operations performed by the cache manager24to demote a track from the first cache14to the second cache18. Upon initiating (at block550) an operation to demote a track from the first cache14to the second cache18, the cache manager14determines (at block552) an eligible track in the first cache14eligible for demotion to the second cache18. A track may be determined to be eligible for demotion according toFIGS. 9,10, and12. If (at block554) the track eligible to demote has modified data, then the cache manager24destages (at block556) the modified data to the second cache18so that the second cache18has the most current modified version of the track. Otherwise, if (at block554) the eligible track is unmodified, then the cache manager24determines (at block558) an extent including the eligible track558. If (at block560) the second cache caching154for the determined extent is not enabled, then the cache manager24selects (at block562) not to demote the eligible track and may discard the eligible track. Otherwise, if the second cache caching154is disabled, then the cache manager24demotes (at block564) the eligible track from the first cache14to the second cache18.

FIG. 19illustrates an embodiment of operations performed by the cache manager24, or another component, e.g.,22,34, to manage the second cache caching154to determine whether to re-enable the second cache caching154after it is disabled. Upon initiating (at block600) management of the second cache caching154setting while disabled, the cache manager24may indicate (at block602) the second cache caching154for the extent as enabled after a predetermined time from when the second cache caching154for the extent was indicated as disabled. Further, while the second cache caching154is disabled, the cache manager24may gather (at block604) extent activity information160for the extent and periodically determine (at block606) the activity for the extent while the extent is stored in the second cache18. If (at block608) the periodically determined activity is greater than the threshold level of activity, then the cache manager24indicates (at block610) the second cache caching154for the extent as disabled because the extent activity is still sufficiently high to warrant maintaining the entire extent in the second cache18. Otherwise, if (at block608) the determined activity for the extent has sufficiently fallen, i.e., determined activity is less than the threshold, then the cache manage24or migration manager34may migrate (at block612) the extent form the second cache18to the storage device10.

In an alternative embodiment, the second cache caching154for the extent may be indicated as enabled in response to determining that the periodically determined level of activity is less than the threshold level of activity.

FIG. 20illustrates an embodiment of operations performed by the cache manager24and migration manager34to manage migration and second cache caching settings154when the second cache18is a read-only cache. Upon initiating (at block630) migration operations, the migration manager34performs the operations inFIG. 17. If (at block634) the extent was not migrated to the second cache18then control ends. Otherwise, if the extent was migrated to the second cache18, then the cache manager18determines (at block636) a level of write/destage164activity and a level of stage/read166activity to the tracks in the extent. If (at block638) the destage/write activity164is sufficiently high, e.g., a proportion of the destage/write activity164to the stage/read activity166for the extent exceed a write-to-read proportion activity threshold, then control ends and the second cache caching setting154remains disabled until the extent is migrated back to the storage10. If the proportion of read activity is sufficiently high, i.e., the proportion of write to reads is low, then the cache manager24performs (at block640) the operations inFIG. 19to determine when to enable the second cache caching154.

Described embodiments provide techniques for managing caching operations with respect to tracks in a second cache that caches tracks between a first cache and a storage. In described embodiments, if an extent of tracks is migrated to the second cache from the storage, then the caching of tracks in the extent from the first cache to the second cache is disabled because the tracks of the extent are already maintained in the first cache. Further, caching to the tracks in the extent may be enabled after a predetermined time or after the extent is migrated from the second cache back to the storage.

The described operations may be implemented as a method, apparatus or computer program product using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. Accordingly, aspects of the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the embodiments may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.