Priority-based CPU multitasking system and method

A method, computer program product, and computing system for executing a first sub-thread of an operating system thread on a central processing unit (CPU) of the computing device. The CPU may be released for a defined period of time. One of an application and a second sub-thread of the operating system thread may be executed based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application.

BACKGROUND

Storing and safeguarding electronic content may be beneficial in modern business and elsewhere. Accordingly, various methodologies may be employed to protect and distribute such electronic content.

In some implementations, an operating system thread may be configured to suspend itself and allow another application to utilize the CPU. One approach detects when an operating system thread is idle in order to suspend the CPU and detects when new events arrive for the operating system thread to schedule back.

However, for a storage system that has continuous background activity, the storage system may not be idle, as the storage system may utilize e.g., 100% CPU most of the time. Since conventional approaches release the CPU by suspending the operating system thread, there may be a significant penalty from unused CPU cycles when other applications do not need the CPU, because these other applications will release the CPU before consuming all the given time, and the operating system thread will get scheduled only when new events are detected. In addition, when no other application needs the CPU, there will be two unnecessary context-switches (e.g., one for suspend and one for resume). As will be discussed in greater detail below, embodiments of the present disclosure may utilize execution priorities to avoid these penalties and achieve an optimized solution for a storage system with background operations.

SUMMARY OF DISCLOSURE

In one example implementation, a computer-implemented method executed on a computing device may include, but is not limited to, executing a first sub-thread of an operating system thread on a central processing unit (CPU) of the computing device. The CPU may be released for a defined period of time. One of an application and a second sub-thread of the operating system thread may be executed based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application.

One or more of the following example features may be included. Releasing the CPU may include lowering the execution priority of the operating system thread below the execution priority of the application. Executing one of the application and the second sub-thread of the operating system thread may include executing the application while the application has an execution priority greater than the execution priority of the operating system thread during the defined period of time. Executing one of the application and the second sub-thread of the operating system thread may include executing the second sub-thread of the operating system thread when the application does not need the CPU. Executing one of the application and the second sub-thread of the operating system thread may include executing the second sub-thread of the operating system thread when the application releases the CPU during the defined period of time. The execution priority of the operating system thread may be raised above the execution priority of the application after the defined period of time. The execution of the application may be disabled by increasing the execution priority of the operating system thread.

In another example implementation, a computer program product resides on a computer readable medium that has a plurality of instructions stored on it. When executed by a processor, the instructions cause the processor to perform operations that may include, but are not limited to, executing a first sub-thread of an operating system thread on a central processing unit (CPU) of the computing device. The CPU may be released for a defined period of time. One of an application and a second sub-thread of the operating system thread may be executed based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application.

One or more of the following example features may be included. Releasing the CPU may include lowering the execution priority of the operating system thread below the execution priority of the application. Executing one of the application and the second sub-thread of the operating system thread may include executing the application while the application has an execution priority greater than the execution priority of the operating system thread during the defined period of time. Executing one of the application and the second sub-thread of the operating system thread may include executing the second sub-thread of the operating system thread when the application does not need the CPU. Executing one of the application and the second sub-thread of the operating system thread may include executing the second sub-thread of the operating system thread when the application releases the CPU during the defined period of time. The execution priority of the operating system thread may be raised above the execution priority of the application after the defined period of time. The execution of the application may be disabled by increasing the execution priority of the operating system thread.

In another example implementation, a computing system includes at least one processor and at least one memory architecture coupled with the at least one processor, wherein the processor is configured to execute a first sub-thread of an operating system thread on a central processing unit (CPU) of the computing device. The processor may be further configured to release the CPU for a defined period of time. The processor may be further configured to execute one of an application and a second sub-thread of the operating system thread based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application.

One or more of the following example features may be included. Releasing the CPU may include lowering the execution priority of the operating system thread below the execution priority of the application. Executing one of the application and the second sub-thread of the operating system thread may include executing the application while the application has an execution priority greater than the execution priority of the operating system thread during the defined period of time. Executing one of the application and the second sub-thread of the operating system thread may include executing the second sub-thread of the operating system thread when the application does not need the CPU. Executing one of the application and the second sub-thread of the operating system thread may include executing the second sub-thread of the operating system thread when the application releases the CPU during the defined period of time. The execution priority of the operating system thread may be raised above the execution priority of the application after the defined period of time. The execution of the application may be disabled by increasing the execution priority of the operating system thread.

DETAILED DESCRIPTION

Referring toFIG. 1, there is shown CPU multitasking process10that may reside on and may be executed by storage system12, which may be connected to network14(e.g., the Internet or a local area network). Examples of storage system12may include, but are not limited to: a Network Attached Storage (NAS) system, a Storage Area Network (SAN), a personal computer with a memory system, a server computer with a memory system, and a cloud-based device with a memory system.

As is known in the art, a SAN may include one or more of a personal computer, a server computer, a series of server computers, a mini computer, a mainframe computer, a RAID device and a NAS system. The various components of storage system12may execute one or more operating systems, examples of which may include but are not limited to: Microsoft® Windows®; Mac® OS X®; Red Hat® Linux®, Windows® Mobile, Chrome OS, Blackberry OS, Fire OS, or a custom operating system. (Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other countries or both; Mac and OS X are registered trademarks of Apple Inc. in the United States, other countries or both; Red Hat is a registered trademark of Red Hat Corporation in the United States, other countries or both; and Linux is a registered trademark of Linus Torvalds in the United States, other countries or both).

The instruction sets and subroutines of CPU multitasking process10, which may be stored on storage device16included within storage system12, may be executed by one or more processors (not shown) and one or more memory architectures (not shown) included within storage system12. Storage device16may include but is not limited to: a hard disk drive; a tape drive; an optical drive; a RAID device; a random access memory (RAM); a read-only memory (ROM); and all forms of flash memory storage devices. Additionally/alternatively, some portions of the instruction sets and subroutines of CPU multitasking process10may be stored on storage devices (and/or executed by processors and memory architectures) that are external to storage system12.

Various IO requests (e.g. IO request20) may be sent from client applications22,24,26,28to storage system12. Examples of IO request20may include but are not limited to data write requests (e.g., a request that content be written to storage system12) and data read requests (e.g., a request that content be read from storage system12).

The instruction sets and subroutines of client applications22,24,26,28, which may be stored on storage devices30,32,34,36(respectively) coupled to client electronic devices38,40,42,44(respectively), may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into client electronic devices38,40,42,44(respectively). Storage devices30,32,34,36may include but are not limited to: hard disk drives; tape drives; optical drives; RAID devices; random access memories (RANI); read-only memories (ROM), and all forms of flash memory storage devices. Examples of client electronic devices38,40,42,44may include, but are not limited to, personal computer38, laptop computer40, smartphone42, notebook computer44, a server (not shown), a data-enabled, cellular telephone (not shown), and a dedicated network device (not shown).

Users46,48,50,52may access storage system12directly through network14or through secondary network18. Further, storage system12may be connected to network14through secondary network18, as illustrated with link line54.

Client electronic devices38,40,42,44may each execute an operating system, examples of which may include but are not limited to Microsoft® Windows®; Mac® OS X®; Red Hat® Linux®, Windows® Mobile, Chrome OS, Blackberry OS, Fire OS, or a custom operating system. (Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other countries or both; Mac and OS X are registered trademarks of Apple Inc. in the United States, other countries or both; Red Hat is a registered trademark of Red Hat Corporation in the United States, other countries or both; and Linux is a registered trademark of Linus Torvalds in the United States, other countries or both).

In some implementations, as will be discussed below in greater detail, a CPU multitasking process, such as CPU multitasking process10ofFIG. 1, may include but is not limited to, executing a first sub-thread of an operating system thread on a central processing unit (CPU) of the computing device. The CPU may be released for a defined period of time. One of an application and a second sub-thread of the operating system thread may be executed based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application.

For example purposes only, storage system12will be described as being a network-based storage system that includes a plurality of electro-mechanical backend storage devices. However, this is for example purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible and are considered to be within the scope of this disclosure.

The Storage System:

Referring also toFIG. 2, storage system12may include storage processor100and a plurality of storage targets T1-n(e.g., storage targets102,104,106,108). Storage targets102,104,106,108may be configured to provide various levels of performance and/or high availability. For example, one or more of storage targets102,104,106,108may be configured as a RAID 0 array, in which data is striped across storage targets. By striping data across a plurality of storage targets, improved performance may be realized. However, RAID 0 arrays do not provide a level of high availability. Accordingly, one or more of storage targets102,104,106,108may be configured as a RAID 1 array, in which data is mirrored between storage targets. By mirroring data between storage targets, a level of high availability is achieved as multiple copies of the data are stored within storage system12.

While storage targets102,104,106,108are discussed above as being configured in a RAID 0 or RAID 1 array, this is for example purposes only and is not intended to be a limitation of this disclosure, as other configurations are possible. For example, storage targets102,104,106,108may be configured as a RAID 3, RAID 4, RAID 5 or RAID 6 array.

While in this particular example, storage system12is shown to include four storage targets (e.g. storage targets102,104,106,108), this is for example purposes only and is not intended to be a limitation of this disclosure. Specifically, the actual number of storage targets may be increased or decreased depending upon e.g., the level of redundancy/performance/capacity required.

Storage system12may also include one or more coded targets110. As is known in the art, a coded target may be used to store coded data that may allow for the regeneration of data lost/corrupted on one or more of storage targets102,104,106,108. An example of such a coded target may include but is not limited to a hard disk drive that is used to store parity data within a RAID array.

While in this particular example, storage system12is shown to include one coded target (e.g., coded target110), this is for example purposes only and is not intended to be a limitation of this disclosure. Specifically, the actual number of coded targets may be increased or decreased depending upon e.g. the level of redundancy/performance/capacity required.

Examples of storage targets102,104,106,108and coded target110may include one or more electro-mechanical hard disk drives and/or solid-state/flash devices, wherein a combination of storage targets102,104,106,108and coded target110and processing/control systems (not shown) may form data array112.

The manner in which storage system12is implemented may vary depending upon e.g. the level of redundancy/performance/capacity required. For example, storage system12may be a RAID device in which storage processor100is a RAID controller card and storage targets102,104,106,108and/or coded target110are individual “hot-swappable” hard disk drives. Another example of such a RAID device may include but is not limited to an NAS device. Alternatively, storage system12may be configured as a SAN, in which storage processor100may be e.g., a server computer and each of storage targets102,104,106,108and/or coded target110may be a RAID device and/or computer-based hard disk drives. Further still, one or more of storage targets102,104,106,108and/or coded target110may be a SAN.

In the event that storage system12is configured as a SAN, the various components of storage system12(e.g. storage processor100, storage targets102,104,106,108, and coded target110) may be coupled using network infrastructure114, examples of which may include but are not limited to an Ethernet (e.g., Layer 2 or Layer 3) network, a fiber channel network, an InfiniBand network, or any other circuit switched/packet switched network.

Storage system12may execute all or a portion of CPU multitasking process10. The instruction sets and subroutines of CPU multitasking process10, which may be stored on a storage device (e.g., storage device16) coupled to storage processor100, may be executed by one or more processors (not shown) and one or more memory architectures (not shown) included within storage processor100. Storage device16may include but is not limited to: a hard disk drive; a tape drive; an optical drive; a RAID device; a random access memory (RAM); a read-only memory (ROM); and all forms of flash memory storage devices. As discussed above, some portions of the instruction sets and subroutines of CPU multitasking process10may be stored on storage devices (and/or executed by processors and memory architectures) that are external to storage system12.

As discussed above, various IO requests (e.g. IO request20) may be generated. For example, these IO requests may be sent from client applications22,24,26,28to storage system12. Additionally/alternatively and when storage processor100is configured as an application server, these IO requests may be internally generated within storage processor100. Examples of IO request20may include but are not limited to data write request116(e.g., a request that content118be written to storage system12) and data read request120(i.e. a request that content118be read from storage system12).

During operation of storage processor100, content118to be written to storage system12may be processed by storage processor100. Additionally/alternatively and when storage processor100is configured as an application server, content118to be written to storage system12may be internally generated by storage processor100.

Storage processor100may include frontend cache memory system122. Examples of frontend cache memory system122may include but are not limited to a volatile, solid-state, cache memory system (e.g., a dynamic RAM cache memory system) and/or a non-volatile, solid-state, cache memory system (e.g., a flash-based, cache memory system).

Storage processor100may initially store content118within frontend cache memory system122. Depending upon the manner in which frontend cache memory system122is configured, storage processor100may immediately write content118to data array112(if frontend cache memory system122is configured as a write-through cache) or may subsequently write content118to data array112(if frontend cache memory system122is configured as a write-back cache).

Data array112may include backend cache memory system124. Examples of backend cache memory system124may include but are not limited to a volatile, solid-state, cache memory system (e.g., a dynamic RAM cache memory system) and/or a non-volatile, solid-state, cache memory system (e.g., a flash-based, cache memory system). During operation of data array112, content118to be written to data array112may be received from storage processor100. Data array112may initially store content118within backend cache memory system124prior to being stored on e.g. one or more of storage targets102,104,106,108, and coded target110.

As discussed above, the instruction sets and subroutines of CPU multitasking process10, which may be stored on storage device16included within storage system12, may be executed by one or more processors (not shown) and one or more memory architectures (not shown) included within storage system12. Accordingly, in addition to being executed on storage processor100, some or all of the instruction sets and subroutines of CPU multitasking process10may be executed by one or more processors (not shown) and one or more memory architectures (not shown) included within data array112.

Further and as discussed above, during the operation of data array112, content (e.g., content118) to be written to data array112may be received from storage processor100and initially stored within backend cache memory system124prior to being stored on e.g. one or more of storage targets102,104,106,108,110. Accordingly, during use of data array112, backend cache memory system124may be populated (e.g., warmed) and, therefore, subsequent read requests may be satisfied by backend cache memory system124(e.g., if the content requested in the read request is present within backend cache memory system124), thus avoiding the need to obtain the content from storage targets102,104,106,108,110(which would typically be slower).

In some implementations, storage processor100may include one or more central processing units (CPUs) (e.g., CPU126). In some implementations, the one or more CPUs may include a multicore CPU. As is known in the art, a multicore CPU may be configured to execute multiple threads or processes concurrently on each core. However, it will be appreciated that CPU126may not be a multicore CPU within the scope of the present disclosure. In some implementations, CPU126may execute one or more applications (e.g., block application128and file application130). A block application (e.g., block application128) may generally execute a single operating system thread per CPU core of a multicore CPU (e.g., CPU126), which may implement block functionality on data array112.

In some implementations, block application128may run on top of a Preemptive Operating System (OS). As is known in the art, a Preemptive OS generally allows the operating system to preempt (i.e. stop) a running operating system thread without the operating system thread's cooperation, and execute something else, for example another operating system thread. An operating system thread may generally include multiple sub-threads as lightweight implementations of the operating system thread. For example, block application128may include an operating system thread (e.g., operating system thread132) with a plurality of sub-threads (e.g., sub-threads134,136). While an example of e.g., one operating system thread with e.g., two sub-threads has been described above, it will be appreciated that any number of operating system threads and sub-threads for each operating system thread may be used within the scope of the present disclosure. In some implementations, a file application (e.g., file application130) may generally organize data as a single piece of information inside a folder within data array112. When data from a particular folder or file needs to be accessed, storage processor100may require a path to locate the data within data array112.

In some implementations, each operating system thread (e.g., operating system thread132) may implement a scheduling component (e.g., scheduling component138) configured to schedule the execution of the plurality of sub-threads (e.g., sub-threads134,136). In some implementations, each operating system thread (e.g., operating system thread132) may be configured to poll its interfaces for new events (e.g., polling for completions of submitted IO requests to data array112) and poll for new IO requests from the user (e.g., client devices38,40,42,44). Accordingly, each operating system thread may fully utilize the CPU or CPU core it is running on, because even when there is no actual work, the operating system thread may continuously check its interfaces. In some implementations, this always-polling design may be optimized for a storage system that requires low latency and high IOPS (I/O per second) as there are no context switches and no interrupts involved.

In some implementations, storage system12may process background operations which may run during the processing of IO requests from a user, but also when no IO requests are present. In some implementations, background operations may include compression, de-duplication, meta-data defragmentation, calculation of RAID protection from media failures, etc. Furthermore, storage system12may defer some background processing to be executed when there is less IO load from the user, to serve IO requests more quickly, thus reducing the latency and improving the storage system performance. In some implementations, background operations may be a fundamental part of storage system12. For example, suppose storage system12includes a log-structured file system (LFS) that performs defragmentation and garbage collection on metadata. Accordingly, the ability to multitask background IO requests may contribute to the efficient operation of storage system12.

As discussed above, suppose storage system12is required to run another application, for example a file application (e.g., file application130). Storage system use patterns may dynamically change over time (i.e. the user of the system can use only the block application for some time and then use only the file application, and it can also use both of them simultaneously, each with a different load that can also change. Therefore, storage system12may be required to dynamically adapt to the user operation pattern of the e.g., two applications to support dynamic load balancing. As will be discussed in greater detail below, CPU multitasking process10may allow storage system12to multitask CPU operations for sub-threads (e.g., sub-threads134,136) of an operating system thread (e.g., operating system thread132) of a block application (e.g., block application128) and other non-block applications (e.g., file application130).

The CPU Multitasking Process:

Referring also toFIGS. 3-12and in some implementations, CPU multitasking process10may execute300via the computing device, a first sub-thread of an operating system thread on a central processing unit (CPU) of the computing device. The CPU may be released302for a defined period of time. One of an application and a second sub-thread of the operating system thread may be executed304based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application.

As will be discussed in greater detail below, implementations of the present disclosure may allow storage system12to multitask CPU operations for sub-threads (e.g., sub-threads134,136) of an operating system thread (e.g., operating system thread132) of a block application (e.g., block application128) and other non-block applications (e.g., file application130) based upon, at least in part, execution priorities assigned to the operating system thread and other non-block applications. In some implementations, an operating system thread may be configured to suspend itself and allow another application to utilize the CPU. One approach detects when an operating system thread is idle in order to suspend the CPU and detects when new events arrive for the operating system thread to schedule back.

However, for a storage system that has continuous background activity, the system may not be idle, as the storage system may utilize e.g., 100% CPU most of the time. Since conventional approaches release the CPU by suspending the operating system thread, there may be a significant penalty from unused CPU cycles when other applications do not need the CPU, because these other applications will release the CPU before consuming all the given time, and the operating system thread will get scheduled only when new events are detected. In addition, when no other application wants the CPU, there will be two unnecessary context-switches (e.g., one for suspend and one for resume). As will be discussed in greater detail below, embodiments of the present disclosure may utilize scheduling priorities to avoid these penalties and achieve an optimized solution for a storage system with background operations.

In some implementations, CPU multitasking process10may execute300via the computing device, a first sub-thread of an operating system thread on a central processing unit (CPU) of the computing device. As discussed above and in some implementations, a block application (e.g., block application128) may include one or more operating system threads (e.g., operating system thread132) executed on a CPU (e.g., CPU126). In some implementations, block application128may generally execute a single operating system thread per CPU core of a multicore CPU (e.g., CPU126), which may implement block functionality on data array112.

In some implementations and as discussed above, an operating system thread may generally include multiple sub-threads as lightweight implementations of an operating system thread. For example, block application128may include an operating system thread (e.g., operating system thread132) with a plurality of sub-threads (e.g., sub-threads134,136).

Referring also to the example ofFIG. 4, suppose CPU multitasking process10executes300a first sub-thread (e.g., sub-thread134) of an operating system thread (e.g., operating system thread132) on a CPU (e.g., CPU126). In this example and as will be discussed in greater detail below, CPU multitasking process10may execute300the first sub-thread (e.g., sub-thread134) of an operating system thread (e.g., operating system thread132) on the CPU with a first execution priority (e.g., execution priority “p0” as shown inFIG. 4).

In some implementations, CPU multitasking process10may release302the CPU for a defined period of time. Referring again to the example ofFIG. 2and in some implementations, CPU multitasking process10may utilize the scheduling component (e.g., scheduling component138) of each operating system thread (e.g., operating system thread132) by determining whether or not to release302the CPU from executing sub-threads of the operating system thread each time the operating system thread (e.g., operating system thread132) switches between sub-threads. In some implementations and because sub-threads generally run for a very short time, this allows CPU multitasking process10to have a very high resolution for making decisions on when and how to release the CPU for other applications. As shown inFIG. 2and in some implementations, operating system thread132may include a CPU release component (e.g., CPU release component140) and a waking component (e.g., waking component142).

In some implementations, the CPU release component (e.g., CPU release component140) may determine whether the operating system thread (e.g., operating system thread132) will give up execution to let the other applications run (e.g., file application130). In some implementations, CPU release component140may make this determination on every sub-thread switch (i.e., switch between sub-threads of operating system thread). In some implementations, CPU release component140may release the CPU at a predefined CPU release interval for a predefined CPU release duration. In some implementations, CPU release component140may release the CPU according to various algorithms. For example, CPU release component140may include various algorithms that may determine when to release the CPU and for how long. In some implementations, when the operating system thread decides (e.g., via CPU release component140) to release the CPU, CPU release component140may post the duration for which it allows the other application to utilize the CPU (e.g., a define period of time), as well as the time it decided to release the CPU. In some implementations, these values (e.g., CPU release duration and CPU release time) may be made be visible to other operating system threads. In some implementations, the defined period of time for releasing the CPU may be user-defined, pre-defined, and/or automatically defined by CPU multitasking process10.

In some implementations, the waking component (e.g., waking component142) may check if there are currently other suspended operating system threads that should be awakened. In some implementations, the waking component may perform this check each sub-thread switch and/or before making the decision whether to give up the CPU, by checking the values (e.g., CPU release duration and CPU release time) posted by the CPU release component of another operating system thread before releasing302the CPU.

In some implementations, conventional approaches for releasing a CPU include an operating system thread suspending itself (e.g. calling to ‘pthread_cond_wait’ in Linux®). However, if no other application are ready to run, conventional approaches get a penalty of two context-switches (i.e. one of suspending the operating system thread, and the second of scheduling back the operating system thread to run). Also, when the other application releases the CPU before consuming the granted time, conventional approached waste CPU cycles until the suspended operating system thread is awakened. Accordingly, CPU multitasking process10may utilize a priority system (e.g. priorities of the Real-Time scheduler in Linux®) of the scheduling component (e.g., scheduling component138) in order to avoid this overhead.

In some implementations, releasing302the CPU may include lowering306the execution priority of the operating system thread below the execution priority of the application for the defined period of time. In some implementations, when the operating system thread (e.g., operating system thread132) releases302the CPU (e.g., CPU126), CPU multitasking process10may lower306the execution priority of the operating system thread to be lower than the other application for the defined period of time. In some implementations and referring again to the example ofFIG. 4, CPU multitasking process10may execute300first sub-thread134with a first execution priority (e.g., execution priority “p0”). In some implementations, the first execution priority (e.g., execution priority “p0”) may be the highest possible priority that is lower than the execution priority of kernel jobs and, as will be discussed in greater detail below, higher than the execution priority of a non-block application (e.g., file application130). In some implementations and as discussed above, CPU multitasking process10may release302the CPU (e.g., after first sub-thread134has finished or has reached a breakpoint) by lowering306the execution priority of operating system thread (e.g., from execution priority “p0” to execution priority “p1”). In this example, CPU multitasking process10may lower306the execution priority of operating system thread132from “p0” to “p1” for the defined period of time starting from time “t0” to “t1” (e.g., the defined period of time).

In some implementations, CPU multitasking process10may execute304one of an application and a second sub-thread of the operating system thread based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application. Referring also to the example ofFIG. 5and in some implementations, CPU multitasking process10may define an execution priority for a non-block application (e.g., file application130) to be lower than that of the operating system thread when the operating system thread is executing a sub-thread (e.g., first sub-thread134) on the CPU (e.g., execution priority “p2”). In one example, suppose file application is ready to be executed on the CPU at time “t0”. Referring also to the example ofFIG. 6, CPU multitasking process10may execute300the first sub-thread (e.g., first sub-thread134) of operating system thread132on the CPU until CPU multitasking process10releases the CPU at time “t0” until time “t1”. As discussed above and in some implementations, CPU multitasking process10may release302the CPU from executing sub-threads of the operating system thread by lowering306the execution priority of operating system thread132from priority “p0” to priority “p1”. In this example, at time “t0”, CPU multitasking process10may execute304file application130based upon, at least in part, an execution priority of the operating system thread and an execution priority of the application. For example, because file application has a higher execution priority (e.g., execution priority “p2”) than the operating system thread (e.g., execution priority “p1”), CPU multitasking process10may execute304file application130on the CPU until time “t1”.

In some implementations, executing304one of the application and the second sub-thread of the operating system thread may include executing308the application while the application has an execution priority greater than the execution priority of the operating system thread during the defined period of time. Referring again to the example ofFIG. 6, CPU multitasking process10may execute308file application130while file application130has an execution priority greater than the execution priority of operating system thread132during the defined period of time (e.g., time between “t0” and “t1”).

In some implementations, executing304one of the application and the second sub-thread of the operating system thread may include executing the second sub-thread of the operating system thread when the application does not need the CPU. Referring also to the example ofFIG. 7and in some implementations, suppose no file application is ready to be executed on the CPU at time “t0”. In this example, operating system thread132may resume its execution (e.g., executing second sub-thread136) because sub-thread136has the highest execution priority. In this example, two context-switches penalties may be avoided as operating system thread does not need to suspend a sub-thread of operating system thread132nor switch back to a previous sub-thread.

Referring again to the example ofFIG. 6, suppose no other applications need the CPU. In this case, no context switch will happen. After waking up at time “t1”, CPU multitasking process10may execute second sub-thread136of operating system thread132thus resuming its normal flow of execution (i.e. poll its interfaces, fetch new events and process all the work that derives from them). In some implementations, when operating system thread132wakes up, it may resume to the exact running model as before.

In some implementations, executing304one of the application and the second sub-thread of the operating system thread may include executing310the second sub-thread of the operating system thread when the application releases the CPU during the defined period of time. Referring also to the examples ofFIGS. 8-9and in some implementations, suppose file application130requires a smaller execution duration (e.g., time between “t0” and “t2”) than the defined period of time during which the CPU is released to file application130. Conventional approaches would result in file application130finishing executing at time “t2” and wasting CPU cycles until time “t1” when operating system132would wake and begin executing second sub-thread136. However, as shown in the example ofFIG. 9, even if file application finishes executing at time “t2”, operating system thread132may be scheduled back by the operating system immediately without any involvement from other operating system threads because operating system thread132has the highest execution priority at time “t2”.

In some implementations, CPU multitasking process10may raise314the execution priority of the operating system thread above the execution priority of the application after the defined period of time. Referring again to the example ofFIG. 6and in some implementations, CPU multitasking process10may raise314the execution priority of operating system thread132after the defined period of time (e.g., after time “t1”) from a lower execution priority (e.g., execution priority “p1”) to a higher execution priority (e.g., execution priority “p0” which is higher than execution priority “p2” used for file applications). In some implementations, CPU multitasking process10may raise314the execution priority of operating system thread132using another operating system thread. For example, CPU multitasking process10may cause another operating system thread to increase the priority of operating system thread132. When its execution priority is increased from execution priority “p1” as shown inFIG. 4to execution priority “p0” as shown inFIG. 6at time “t1”, operating system thread132may immediately get scheduled back and execute304second sub-thread136on the CPU.

Referring also to the examples ofFIGS. 10-11and in some implementations, suppose file application130requires more time to execute (e.g., time between “t0” and “t3”) than the defined amount of time the CPU is released to file application130(e.g., time between “t0” and “t1”). In this example, file application130may consume all of its granted time (e.g., time between “t0” and “t1”). In this case, CPU multitasking process10may cause another operating system thread to increase the priority of operating system thread132. When its execution priority is increased (as shown inFIG. 11at time “t1”), operating system thread132may immediately get scheduled back and execute304second sub-thread136on the CPU.

In some implementations, to avoid a deadlock situation where all operating system threads release their CPU core or release the CPU so there is no running operating system thread that can wake another operating system thread, CPU multitasking process10may ensure that at least one operating system thread is always running. For example and before releasing302the CPU, CPU multitasking process10may determine that at least one operating system thread is running and will not release the CPU if all the other operating system threads are currently suspended. In some implementations, when other operating system threads schedule back a suspended operating system thread, after checking its posted values, the other operating system thread may increase its scheduling priority back to the previous execution priority (e.g., execution priority “p0”).

In some implementations, CPU multitasking process10may disable316the execution of the application by increasing the execution priority of the operating system thread. Referring also to the example ofFIG. 12and in some implementations, CPU multitasking process10may be easily and quickly enabled or disabled without disrupting the block application (e.g., block application128) and while the storage system (e.g., storage system12) is active. In some implementations, CPU multitasking process10may disable316the execution of the application by raising all operating system threads priorities and instructing them not to release the CPU. As shown in the example of FIG.12, CPU multitasking process10may disable316the execution of file application130by increasing or raising the execution priority of operating system thread132(e.g., execution priority “p0”) above the execution priority of file application130(e.g., execution priority “p2”) and preventing CPU multitasking process10from releasing302the CPU while the functionality is disabled. In some implementations, disabling316the execution of the application may include setting a flag or other variable within storage processor100and/or CPU126. In some implementations, the flexibility to disable316the releasing302of CPU126and execution304of the application based upon, at least in part, the priority of the operating system thread and the application may be significant, because when there is only a block application running, CPU multitasking process10completely eliminate the overhead associated with releasing302the CPU to other non-block applications. In some implementations, CPU multitasking process10may quickly resume CPU multitasking to release302the CPU to non-block applications when a non-block application (e.g., file application130) is ready.

As discussed above and in some implementations of the present disclosure, CPU multitasking process10may guarantee that the operating system threads will not get preempted by the operating system and will continue to run until they voluntarily release the CPU, even if other applications are ready to run. It may also guarantee that when a suspended operating system thread becomes ready to run after another operating system thread increases its execution priority, the operating system will immediately preempt the other application and schedule the ready operating system thread.