Selective Throttling of Workflow Tools

With advances in computing device technology, workflow management in computing environments faces a significant challenge in efficiently executing complex, multi-stage tasks while optimizing resource utilization. Workflow management has become increasingly important due to the growing reliance on interconnected systems to process large volumes of data and perform diverse operations in workflows involving tasks that must be completed atomically, tasks that are permitted to be performed in parallel, and combinations thereof. The ability to dynamically manage and prioritize tasks within workflows is crucial for maintaining computing system performance and ensuring cost-effective resource allocation.

Selective throttling of workflow tools is described. In implementations, a computing device receives a workflow configured to generate an output by processing data using a plurality of tools. The plurality of tools include one or more upstream tools and one or more downstream tools, where the upstream tools are configured to generate tasks for subsequent execution by one or more of the downstream tools. The computing device executes the workflow by first generating the tasks using the one or more upstream tools. These generated tasks are then maintained in a queue. The output is generated by releasing individual tasks from the queue to the appropriate tools among the one or more downstream tools. During the execution of the workflow, the computing device monitors the queue and detects when at least one throttle threshold condition is satisfied due to the tasks being maintained in the queue. When a throttle threshold condition is detected, the computing device responds by throttling at least one tool among the one or more upstream tools. The computing device continues to monitor the queue and detects when a resume threshold condition is satisfied (e.g., due to tasks being removed from the queue responsive to execution by one or more of the downstream tools). In response to detecting the resume threshold condition, the computing device resumes or “unthrottles” the previously throttled tool. The computing device continues to monitor workflow queues and selectively throttles/resumes workflow tools to optimize performance until execution of the workflow is complete.

This Summary introduces a selection of concepts in a simplified form that are further described below in the Detailed Description. As such, this Summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

With advances in computing device technology, increasingly complex workflows are generated to perform computational tasks. In accordance with the techniques described herein, a workflow refers to one or more sequences of interconnected tools that collectively operate to achieve one or more objectives (e.g., generate at least one output by processing data). For example, a workflow may include data ingestion tools to obtain data from one or more data storage locations, processing tools to manipulate the data according to defined algorithmic steps, analysis tools to generate insights based on input data, reporting tools to produce an output in a defined format, and so forth.

Workflows are often created using programming languages, where a workflow author (e.g., an application developer) writes instructions for each workflow tool that are executed by a computing device to preform functionality of the corresponding tool. In some implementations, workflows are developed using a graphical programming language where authoring users are provided with palettes of tools that can be dragged onto a canvas and connected with one another to create a workflow without having to manually author code for executing functionality of the corresponding tools.

Individual tools of a workflow often generate outputs in the form of tasks that need to be subsequently executed by one or more different tools of the workflow in order to achieve a desired objective. For instance, as a simple example, consider a workflow involving three tools: a first tool to obtain encrypted data from one or more data storage locations and decrypt the data, a second tool to sort the data according to defined arrangement criteria, and a third tool to generate an output report that presents the sorted data in a defined format. In this example, an entirety of the unencrypted data must be available for the second tool to analyze before it can begin sorting, such that the second tool cannot begin performing its functionality until the first tool has completed its data decryption. Continuing this example implementation, an output by the first tool can be regarded as a task to be performed by the second tool, where this task is held (e.g., in a queue) until the first tool is finished. Thus, relative to the task as held in the queue, the first tool is regarded as an upstream tool and the second tool is regarded as a downstream tool.

Thus, as described herein, the terms “upstream tools” and “downstream tools” in workflow management do not refer to a fixed, linear ordering of tools, but rather describe their logical relationship to a task queue that serves as an intermediary buffer for holding tasks until they can be executed (e.g., based on computational resource availability, based on conditions that require waiting for other tools to finish processing, combinations thereof, and so forth). Upstream tools are considered “upstream” because they produce work that flows towards the queue, regardless of their position in the overall workflow sequence.

Conversely, downstream tools consume and execute the tasks held in the queue, receiving work that flows from the queue. This queue-centric perspective allows for complex, non-linear workflow structures, including parallel processing, branching workflows, and feedback loops. In implementations, a workflow tool's role as upstream or downstream might change dynamically depending on the specific operation being performed. For instance, in one scenario, Tool A might generate tasks for Tool B (making A upstream and B downstream), while in another scenario during the same workflow, roles of Tool A and Tool B are reversed. In some implementations, a workflow involves multiple queues, where a given tool is downstream relative to one queue and upstream relative to another queue.

Given the complexity of different workflows that can be created to accomplish different objectives, workflow management faces a significant challenge in efficiently executing complex, multi-stage workflows while optimizing resource utilization, particularly when workflows are executed using distributed computing environments. Workflow management has become increasingly important due to the growing reliance on interconnected systems to process large volumes of data and perform diverse operations involving tasks that must be completed atomically, tasks that are permitted to be performed in parallel, and combinations thereof. The ability to dynamically manage and prioritize tasks within workflows is crucial for maintaining computing system performance and ensuring cost-effective resource allocation.

Conventional approaches to workflow management lack the ability to exercise fine-grained control over tool execution rates, involve inefficient resource utilization across different workflow stages, and suffer from an inability to dynamically adjust generation and execution of workflow tasks based on real-time system conditions. Traditional workflow management tools struggle to balance the processing of tasks with varying resource requirements, leading to bottlenecks and suboptimal performance. Additionally, given the complexity of modern workflows, with their multiple dependencies and varying priorities, it remains challenging to implement effective task prioritization and resource allocation strategies.

For instance, in implementations where certain tasks consume disproportionate amounts of processing power or memory, conventional workflow management approaches fail to adequately throttle these resource-intensive operations, resulting in overall workflow slowdowns. When dealing with workflows where concurrent tools compete for shared resources (e.g., processing devices, memory, etc.) to complete respective tasks, conventional systems lack the capability to intelligently distribute resources across different tools, leading to inefficiencies and conflicts in resource allocation. Thus, there remains a need for workflow management approaches that adapt to dynamic computing environments.

To address these conventional shortcomings, selective throttling of workflow tasks is described. In implementations, a computing system receives a workflow comprised of a plurality of tools that are collectively configured to perform a computational task by processing data, as generally described above. The computing system is configured to perform the computational task by executing code (e.g., using one or more processing devices) corresponding to each tool in the workflow. During execution of the workflow, the computing system is configured to maintain at least one queue for storing tasks to be completed by one or more workflow tools as part of executing the workflow. During execution of a workflow, data output by a first workflow tool is used as input for a second workflow tool in order for the second workflow tool to perform its respective functionality in completing the computational task. In many hardware architectures, different workflow tools share hardware resources (e.g., processor cores, compute units, cache storage, etc.) when performing their respective functionalities, such that tools otherwise permitted to execute in parallel are unable to do so based on computational resource constraints.

Alternatively or additionally, some workflow tools require atomicity. As described herein, “atomicity” refers to indivisible operations that are required to be performed serially and without interruption (e.g., a database transaction that must either complete entirely or not occur at all, ensuring data consistency even if underlying hardware fails during execution). Given hardware resource constraints, atomicity requirements, and other considerations, workflow execution necessitates that certain tasks (e.g., data and corresponding instructions for processing the data) be maintained in the queue until downstream tools are available and/or permitted to execute the queued tasks.

To enable the techniques described herein, a computing system includes a scheduler, which represents functionality of the computing system to release tasks from the queue for execution by one or more downstream workflow tools. The scheduler, for instance, monitors the queue and available hardware resources of the computing system to identify when hardware resources are available for allocation to a downstream tool, such that the downstream tool is capable of executing a queued task.

When too many tasks accumulate in a queue, several problems can arise that impact system performance and efficiency. As a number of queued workflow tasks grows, the queued tasks may exceed the capacity of rapidly accessible data storage locations like cache systems, forcing the system to rely on slower main memory for task storage. This transition from cache to main memory increases access times and requires additional computational resources, leading to slower task execution and reduced overall workflow efficiency. Furthermore, maintaining an excessive number of tasks in queue consumes valuable memory resources that could be better utilized for other workflow tools, critical system operations, and so forth.

At a certain point, the computational overhead of managing and accessing a large queue outweighs the benefits of executing upstream tools to generate tasks that are sent to the queue. This inefficiency manifests as increased memory management operations, higher latency in task retrieval, and potential system slowdowns due to memory pressure. Additionally, a bloated queue can lead to outdated or stale tasks if the workflow conditions change rapidly, potentially resulting in wasted processing of irrelevant tasks. Therefore, it becomes computationally wasteful to continue queuing additional tasks beyond an optimal threshold, as the marginal benefit of having more pre-generated tasks is outweighed by the increased system overhead and potential for resource contention.

To account for these problems, the scheduler is configured to monitor the queue relative to one or more throttle threshold conditions. As described herein, throttle threshold conditions refer to criteria that, when detected, trigger the scheduler to throttle one or more upstream workflow tools to manage task generation and queue growth. These throttle threshold conditions are configurable based on a range of factors related to the task queue and underlying system resources of a computing system executing the workflow. For instance, in an example implementation a throttle threshold condition specifies a predetermined limit of tasks permitted to be maintained in the queue (e.g., to prevent memory overload).

Alternatively or additionally, a throttle threshold condition specifies a total data size of queued tasks, initiating throttling when the queue consumes more than a threshold amount of memory. Alternatively or additionally, system resource utilization serves as a throttle threshold condition, such as throttling upstream tools when available processing device usage exceeds a defined percentage, when available memory drops below a threshold percentage, combinations thereof, and so forth. Alternatively or additionally, throttle threshold conditions include time-based thresholds, triggering throttling if tasks remain in the queue for longer than a specified duration, indicating potential processing bottlenecks. Alternatively or additionally, throttle threshold conditions include temperature thresholds, such that a temperature of a computing system component triggers throttling of a workflow tool to prevent system damage. Alternatively or additionally, custom thresholds are configurable based on workflow-specific metrics, such as throttling when the ratio of incoming tasks to outgoing tasks (e.g., relative to the queue) exceeds a certain value, indicating an imbalance in task generation and consumption rates. These examples are merely illustrative and not intended to limit throttle thresholds in accordance with the techniques described herein.

In response to detecting occurrence of a throttle threshold condition, the scheduler is configured to identify an upstream workflow tool contributing to occurrence of the throttle threshold condition and throttle the identified tool to reduce an amount of tasks being generated and sent to the queue. In implementations, the scheduler employs various strategies to identify upstream workflow tools contributing to throttle threshold conditions. In one example implementation, the scheduler analyzes task generation rates of individual upstream tools and compares the task generation rates to determine which tool is producing tasks at a disproportionately high rate relative to others.

Alternatively or additionally, the scheduler is configured to examine metadata associated with queued tasks, allowing the scheduler to pinpoint tools contributing most significantly to queue congestion. Alternatively or additionally, the scheduler considers the computational complexity or resource requirements of tasks generated by different tools, prioritizing the identification of tools producing resource-intensive tasks that strain system capabilities. Alternatively or additionally, historical performance data is utilized to identify tools that have previously led to satisfaction of throttle threshold conditions (e.g., during prior execution of workflows involving similar tools). Alternatively or additionally, the scheduler is configured to take into account the relative importance or priority of different workflow stages, focusing on non-critical path tools when possible to minimize impact on overall workflow performance.

Alternatively or additionally, the scheduler is configured to employ machine learning algorithms to predict which tool's throttling would most effectively alleviate queue congestion based on current workflow patterns and system state. Alternatively or additionally, the scheduler is configured to analyze current system resource utilization associated with each tool's operation, identifying tools consuming excessive resources as potential candidates for throttling. These varied approaches enable the scheduler to adaptively identify and manage upstream tools contributing to throttle conditions, optimizing workflow execution in diverse computing environments. In response to identifying one or more tools contributing to satisfaction of the throttling threshold condition, the scheduler throttles the identified tool(s).

In accordance with the described techniques, throttling of workflow tools can be implemented in diverse ways depending on specific workflow requirements and system constraints. In some implementations, throttling involves pausing the operation of an upstream tool, temporarily halting its task generation until system conditions improve. Alternatively, throttling is applied by reducing a rate at which a tool generates tasks, allowing the tool to continue functioning at a limited pace. This rate reduction may be achieved by introducing delays between task generations, limiting the number of tasks the tool can produce within a given time limit, adjusting internal parameters that control the tool's processing speed, combinations thereof, and so forth. The specific throttling approach implemented by the scheduler may depend on factors such as the nature of the workflow, the severity of the queue congestion, criticality of the tool's operations, combinations thereof, and so forth.

After throttling one or more upstream workflow tools, the scheduler continues to monitor the queue for satisfaction of resume threshold conditions. In implementations, resume threshold conditions may differ from throttle threshold conditions to prevent rapid oscillation between throttling and resuming operations. For instance, while a throttle threshold might trigger when the queue reaches 90% capacity, the corresponding resume threshold may be satisfied when the queue drops below 70% capacity, providing a buffer zone for system stability. Resume threshold conditions are configurable similar to throttle threshold conditions, such that any metric useable to trigger throttling a tool is useable to trigger resumption of the tool, and vice versa. Resume thresholds may also consider factors such as the rate of task consumption by downstream tools, available system resources, time elapsed since throttling was initiated, combinations thereof, and so forth. In some implementations, the scheduler is configured to employ adaptive algorithms to dynamically adjust resume thresholds based on observed system behavior and workflow patterns.

When resume threshold conditions are satisfied, the scheduler initiates the process of “unthrottling,” or resuming normal operation of previously throttled tools. This resumption may occur gradually, with the scheduler incrementally increasing the task generation rate of the throttled tool until it reaches its pre-throttled state. Alternatively, in some implementations the scheduler is configured to immediately restore a throttled tool to full operational capacity. The specific approach to resuming operations may depend on the nature of the workflow, the current system state, and the potential impact on overall workflow performance, combinations thereof, and so forth. Throughout workflow execution, the scheduler continues to monitor both throttle and resume thresholds, maintaining the ability to re-throttle tools as necessary to ensure optimal workflow execution and resource utilization.

The techniques are described herein with respect to a single workflow queue for simplicity of explanation, but are not so limited. In implementations, a workflow can be configured to include any number of queues, each serving as an intermediary buffer between different sets of upstream and downstream tools. The scheduler is configured to simultaneously monitor multiple queues within a single workflow, applying the described throttling and resuming techniques to upstream tools relative to each respective queue. This multi-queue capability allows for more complex workflow structures, such as those with parallel processing branches, nested sub-workflows, or hierarchical task management. In such scenarios, the scheduler dynamically assesses the state of each queue, considering factors such as queue size, task complexity, and resource utilization specific to the tools interacting with that queue.

The scheduler may implement queue-specific throttle and resume thresholds, allowing for fine-grained control over different workflow segments. This approach enables the system to optimize performance across various workflow stages concurrently, balancing task generation and execution across multiple queues to maintain overall workflow efficiency. The ability to manage multiple queues simultaneously enhances the system's adaptability to diverse and complex workflow architectures, ensuring efficient resource allocation and task management throughout the entire workflow execution process. Further discussion of these and other examples is included in the following description and illustrated with respect to the corresponding figures.

In some aspects, the techniques described herein relate to a method implemented by at least one computing device, the method including: receiving a workflow configured to generate an output by processing data using a plurality of tools, the plurality of tools including a set of upstream tools and a set of downstream tools, the set of upstream tools configured to generate tasks for subsequent execution by one or more tools included in the set of downstream tools; executing the workflow by: generating the tasks using the set of upstream tools; maintaining the tasks in a queue; and generating the output by releasing individual ones of the tasks in the queue to the one or more tools included in the set of downstream tools; and during the executing the workflow: detecting satisfaction of at least one throttle threshold condition due to maintaining the tasks in the queue; and throttling at least one tool in the set of upstream tools.

In some aspects, the techniques described herein relate to a method, wherein generating the tasks for subsequent execution by the one or more tools included in the set of downstream tools includes processing the data, wherein each of the tasks for subsequent execution by the one or more tools included in the set of downstream tools includes: at least one instruction to be executed by a processing device of the at least one computing device; and information describing at least some of the data involved in executing the at least one instruction.

In some aspects, the techniques described herein relate to a method, wherein each of the tasks for subsequent execution by the one or more tools included in the set of downstream tools is maintained in the queue with information describing a source tool in the set of upstream tools that generated the task.

In some aspects, the techniques described herein relate to a method, wherein throttling the at least one tool in the set of upstream tools includes identifying the at least one tool as causing satisfaction of the at least one throttle threshold condition based on the information describing, for each of the tasks maintained in the queue, a corresponding source tool that generated the task.

In some aspects, the techniques described herein relate to a method, wherein releasing individual ones of the tasks in the queue to the one or more tools included in the set of downstream tools is performed responsive to detecting that the at least one computing device includes sufficient available resources for executing the individual ones of the tasks.

In some aspects, the techniques described herein relate to a method, wherein the sufficient available resources include a threshold number of available processing devices.

In some aspects, the techniques described herein relate to a method, wherein the sufficient available resources include a threshold amount of memory allocated to the at least one computing device.

In some aspects, the techniques described herein relate to a method, wherein throttling the at least one tool in the set of upstream tools includes identifying the at least one tool in the set of upstream tools as disproportionately generating tasks relative to other tools of the set of upstream tools during execution of the workflow.

In some aspects, the techniques described herein relate to a method, wherein throttling the at least one tool in the set of upstream tools includes pausing the at least one tool in the set of upstream tools.

In some aspects, the techniques described herein relate to a method, wherein throttling the at least one tool in the set of upstream tools includes limiting an amount of tasks the at least one tool is permitted to generate or limiting a rate at which the at least one tool is permitted to generate tasks.

In some aspects, the techniques described herein relate to a method, wherein throttling the at least one tool in the set of upstream tools is performed independent of throttling other tools in the set of upstream tools.

In some aspects, the techniques described herein relate to a method, further including detecting satisfaction of at least one resume threshold and causing the at least one tool in the set of upstream tools to continue functioning without throttling in response to detecting satisfaction of the at least one resume threshold.

In some aspects, the techniques described herein relate to a method, wherein the at least one resume threshold includes one or more of: a number of tasks maintained in the queue; an amount of data required by the tasks maintained in the queue; a number of available processing devices; an amount of available memory; or a temperature of the at least one computing device.

In some aspects, the techniques described herein relate to a method, further including dynamically modifying the at least one resume threshold during the executing the workflow based on one or more of: a number of tools included in the set of upstream tools; a number of available processing devices; an amount of available memory; a distance between the throttled at least one upstream tool relative to the queue in the workflow; or a distance between at least one downstream tool in the set of downstream tools relative to the queue in the workflow.

In some aspects, the techniques described herein relate to a method, wherein the at least one throttle threshold condition includes one or more of: a number of tasks maintained in the queue; an amount of data required by the tasks maintained in the queue; a number of available processing devices; an amount of available memory; or a temperature of the at least one computing device.

In some aspects, the techniques described herein relate to a method, further including dynamically modifying the at least one throttle threshold condition during the executing the workflow based on one or more of: a number of tools included in the set of upstream tools; a number of available processing devices; an amount of available memory; a distance between the throttled at least one upstream tool relative to the queue in the workflow; or a distance between at least one downstream tool in the set of downstream tools relative to the queue in the workflow.

In some aspects, the techniques described herein relate to a method, further removing the individual ones of the tasks from the queue in response to releasing the individual ones of the tasks from the queue to the one or more tools included in the set of downstream tools.

In some aspects, the techniques described herein relate to a method, wherein the at least one resume threshold causes the at least one computing device to continually execute queued tasks using the one or more tools included in the set of downstream tools until completion of executing the workflow.

In some aspects, the techniques described herein relate to a system including: at least one processor; and a computer-readable storage medium storing instructions that, when executed by the at least one processor, cause the at least one processor to: receive a workflow configured to generate an output by processing data using a plurality of tools, the plurality of tools including a set of upstream tools and a set of downstream tools, the set of upstream tools configured to generate tasks for subsequent execution by one or more tools included in the set of downstream tools; execute the workflow by: generating the tasks using the set of upstream tools; maintaining the tasks in a queue; and generating the output by releasing individual ones of the tasks in the queue to the one or more tools included in the set of downstream tools; and during execution of the workflow: detect satisfaction of at least one throttle threshold condition due to maintaining the tasks in the queue; and throttle at least one tool in the set of upstream tools.

In some aspects, the techniques described herein relate to a computer-readable storage medium storing instructions that are executable by at least one processing device to perform operations including: receiving a workflow configured to generate an output by processing data using a plurality of tools, the plurality of tools including a set of upstream tools and a set of downstream tools, the set of upstream tools configured to generate tasks for subsequent execution by one or more tools included in the set of downstream tools; executing the workflow by: generating the tasks using the set of upstream tools; maintaining the tasks in a queue; and generating the output by releasing individual ones of the tasks in the queue to the one or more tools included in the set of downstream tools; and during the executing the workflow: detecting satisfaction of at least one throttle threshold condition due to maintaining the tasks in the queue; and throttling at least one tool in the set of upstream tools.

In the following discussion, an example environment is described that is configured to employ the techniques described herein. Example procedures are also described that are configured for performance in the example environment as well as other environments. Consequently, performance of the example procedures is not limited to the example environment and the example environment is not limited to performance of the example procedures.

1 FIG. 6 FIG. 100 100 102 102 is an illustration of a digital medium environmentin an example implementation that is operable to employ the selective throttling of workflow tool techniques described herein. The illustrated environmentincludes a computing system. The computing systemis configurable in a variety of manners. A computing system, for instance, is configurable as a desktop computer, a laptop computer, a mobile device (e.g., assuming a handheld configuration such as a tablet or mobile phone), and so forth. Thus, a computing system ranges from full resource devices with substantial memory and processor resources (e.g., personal computers, game consoles) to a low-resource device with limited memory and/or processing resources (e.g., mobile devices). Additionally, although a single computing system is shown and described in instances in the following discussion, a computing system is also representative of a plurality of different devices, such as multiple servers utilized by an entity to perform operations “over the cloud,” as further described in relation to.

102 102 104 106 106 108 104 110 104 110 1 110 110 104 112 114 106 112 114 1 FIG. n Computing systemis representative of a combination of hardware and software resources (e.g., instructions stored on a computer-readable storage medium that are executed by at least one processing device) to perform computational tasks. To do so, the computing systemincludes at least one processing deviceand a data storage system, where the processing device is connected to the data storage systemvia connection/interface. In one or more implementations, the processing deviceincludes multiple cores. For instance, in the illustrated example of, processing deviceis depicted as including core() and core(), where n represents any integer. Coresof the processing deviceare configured to carry out workflowby executing instructions corresponding to individual tools of the workflow using data stored in memoryof the data storage system. As described above, the workflowincludes at least one sequence of interconnected tools that collectively operate to achieve one or more objectives, such as generating an output by processing data stored in memory.

104 106 108 102 1 FIG. In accordance with the described techniques, the processing deviceand the data storage systemare coupled to one another via a wired or wireless connection, which is depicted in the illustrated example ofas the connection/interface. Example wired connections include, but are not limited to, buses (e.g., a data bus), interconnects, traces, and planes. Examples of devices in which the computing systemis implemented include, but are not limited to, supercomputers and/or computer clusters of high-performance computing (HPC) environments, servers, personal computers, laptops, desktops, game consoles, set top boxes, tablets, smartphones, mobile devices, virtual and/or augmented reality devices, wearables, medical devices, systems on chips, and other computing devices or systems.

104 114 104 110 110 Processing deviceis an electronic circuit that performs various operations on and/or using data in the memory. Examples of the processing deviceand/or a coreof the processing device include, but are not limited to, a CPU, a GPU, a field programmable gate array (FPGA), an accelerated processing unit (APU), and a digital signal processor (DSP). For example, in one or more implementations a coreis a processing unit that reads and executes instructions (e.g., of a program involving at least one workflow), examples of which include to add data, to move data, to branch data, and so forth.

106 114 114 106 106 106 114 106 114 In one or more implementations, the data storage systemis a circuit board (e.g., a printed circuit board), on which the memoryis mounted. In some variations, one or more integrated circuits of the memoryare mounted on the circuit board of the data storage system. Examples of the data storage systeminclude, but are not limited to, a TransFlash memory module, a single in-line memory module (SIMM), and a dual in-line memory module (DIMM). In one or more implementations, the data storage systemis a single integrated circuit device that incorporates the memoryon a single chip. In some examples, the data storage systemis composed of multiple chips that implement the memorythat are vertically (“3D”) stacked together, are placed side-by-side on an interposer or substrate, or are assembled via a combination of vertical stacking or side-by-side placement.

114 110 104 114 114 The memoryis a device or system that is used to store information, such as for immediate use in a device (e.g., by a coreof the processing device). In one or more implementations, the memorycorresponds to semiconductor memory where data is stored within memory cells on one or more integrated circuits. In at least one example, the memorycorresponds to or includes volatile memory, examples of which include random-access memory (RAM), dynamic random-access memory (DRAM), synchronous dynamic random-access memory (SDRAM), and static random-access memory (SRAM).

114 110 104 114 114 114 In some implementations, the memorycorresponds to or includes a cache memory of the coreand/or the processing devicesuch as a level 1 cache, a level 2 cache, a level 3 cache, and so forth. For example, the memoryrepresents high bandwidth memory (HBM) in a 3D-stacked implementation. Alternatively or additionally, the memorycorresponds to or includes non-volatile memory, examples of which include solid state disks (SSD), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electronically erasable programmable read-only memory (EEPROM). The memoryis thus configurable in a variety of ways without departing from the spirit or scope of the described techniques.

1 FIG. 1 FIG. 112 116 112 116 114 118 102 118 120 116 122 112 In the illustrated example of, the workflowincludes at least one upstream toolthat is configured to generate tasks for execution by at least one downstream tool of the workflow. To buffer tasks generated by an upstream tool, the memoryincludes a task queuethat is configured to maintain workflow tasks generated by an upstream tool until sufficient computing systemresources are available for a downstream tool to execute a queued workflow task. For instance, in the illustrated example of, the task queuemaintains a workflow taskgenerated by an upstream toolfor subsequent execution by at least one downstream toolof the workflow.

104 124 102 112 124 126 128 130 128 130 116 112 The processing deviceis depicted as including a scheduler, which represents functionality of the computing systemto manage execution of the workflowin accordance with the techniques described herein. To do so, the schedulerincludes a tool identifierfor recognizing specific workflow tools, as well as respective sets of throttle threshold conditionsand resume threshold conditions. As described above, the throttle threshold conditionsand the resume threshold conditionsare used by the scheduler to determine when to throttle or resume, respectively, at least one upstream toolduring execution of the workflow.

112 124 118 128 128 124 116 116 118 120 118 During execution of the workflow, the schedulermonitors the task queuerelative to throttle threshold conditions. In accordance with the described techniques, throttle threshold conditionsrefer to criteria that, when detected, trigger the schedulerto throttle one or more upstream workflow toolsto manage task generation by the at least one upstream tool, and corresponding growth of tasks in the task queue. For instance, a throttle threshold condition may specify a predetermined limit of taskspermitted to be maintained in the queue, or a total data size of queued tasks.

128 124 116 128 118 124 In response to detecting the occurrence of a throttle threshold condition, the scheduleridentifies an upstream workflow toolcontributing to occurrence of the throttle threshold conditionsand throttles the identified tool to reduce the number of tasks being generated and sent to the queue. As described herein, the scheduleris configured to employ various strategies to identify such tools, including analyzing task generation rates, examining task metadata, considering the computational complexity of tasks generated by different tools, combinations thereof, and so forth.

116 124 118 130 130 128 130 128 116 130 124 116 112 124 128 102 After throttling one or more upstream workflow tools, the schedulercontinues to monitor the queuefor satisfaction of resume threshold conditions. In some implementations, the resume threshold conditionsare satisfied when the throttle threshold conditionsare not satisfied. Alternatively, in some implementations the resume threshold conditionsdiffer from throttle threshold conditions(e.g., to prevent rapid oscillation between throttling and resuming operation of at least one upstream tool). When resume threshold conditionsare satisfied, the schedulerinitiates the process of “unthrottling,” or resuming normal operation of a previously throttled one upstream tool. Throughout execution of the workflow, the schedulermaintains the ability to re-throttle tools as necessary (e.g., responsive to detecting satisfaction of throttle threshold conditions), ensuring optimal workflow execution and resource utilization by the computing system.

102 112 124 116 128 130 2 FIG. For a further description of the computing systemexecuting a workflowand using the schedulerto selectively throttle and resume at least one upstream toolbased on throttle threshold conditionsand resume threshold conditions, respectively, consider.

In general, functionality, features, and concepts described in relation to the examples above and below are employed in the context of the example procedures described in this section. Further, functionality, features, and concepts described in relation to different figures and examples in this document are interchangeable among one another and are not limited to implementation in the context of a particular figure or procedure. Moreover, blocks associated with different representative procedures and corresponding figures herein are applicable together and/or combinable in diverse ways. Thus, individual functionality, features, and concepts described in relation to different example environments, devices, components, figures, and procedures herein are usable in any suitable combinations and are not limited to the particular combinations represented by the enumerated examples in this description.

2 FIG. 2 FIG. 200 112 112 116 122 116 200 118 116 122 depicts a systemin an example implementation showing operation of executing a workflowin accordance with the techniques described herein. In the illustrated example of, the workflowincludes at least one upstream toolthat is configured to generate tasks for execution by at least one downstream tool. To buffer tasks generated by an upstream tool, the systemincludes a task queuethat is configured to maintain workflow tasks generated by an upstream tooluntil sufficient computing system resources are available for a downstream toolto execute a queued workflow task.

2 FIG. 118 120 116 122 120 202 112 120 204 114 202 120 206 116 120 For instance,depicts the task queueas maintaining a workflow taskgenerated by an upstream toolfor subsequent execution by at least one downstream tool. The workflow taskis representative of information including task instructions, which represent at least one instruction to be executed by a processing device of a computing system executing the workflow. The workflow taskis further representative of information specifying data, which corresponds to data stored in memorythat is accessed as part of executing the task instruction. Additionally, in some implementations the workflow taskincludes information describing source tool metadata, is representative of information describing the upstream toolthat generated the workflow task.

112 124 118 128 124 128 124 116 206 120 118 124 116 118 During execution of the workflow, the schedulermonitors the task queuerelative to throttle threshold conditions. When the schedulerdetects satisfaction of at least one throttle threshold condition, the scheduleridentifies an upstream toolcontributing to occurrence of the throttle threshold condition (e.g., based on respective source tool metadataassociated with workflow tasksmaintained in the task queue). The schedulerthen throttles the identified upstream toolto reduce an amount of tasks being generated and sent to the task queue.

120 118 122 202 204 208 118 124 116 As individual workflow tasksare released from the task queueto appropriate downstream tools, the respective downstream tools execute the task instructionsusing the associated datato generate a workflow output. The scheduler continues to monitor the task queuefor satisfaction of resume threshold conditions. When resume threshold conditions are satisfied, the schedulerresumes normal operation of previously throttled upstream tools.

116 200 200 120 112 3 FIG. This process of selectively throttling and resuming upstream toolsbased on monitored queue conditions allows the systemto optimize workflow execution and resource utilization. By dynamically managing task generation and queue growth, the systemensures efficient processing of workflow taskswhile preventing queue overflow and maintaining overall system performance throughout execution of the workflow. For a further description of executing a workflow in accordance with the described techniques, consider.

3 FIG. 3 FIG. 3 FIG. 3 FIG. 300 302 304 306 308 310 312 314 316 318 320 322 324 326 328 330 332 312 322 112 depicts a systemillustrating an example workflow structure with multiple interconnected tools and task queues. Specifically, the workflow illustrated inincludes tool, tool, tool, tool, tool, task queue, tool, tool, tool, tool, task queue, and tool. The illustrated example offurther depicts logical boundaries, represented by first boundary, second boundary, third boundary, and fourth boundary, to demonstrate how workflow tools are regarded as upstream or downstream based on their position relative to tasks maintained in a corresponding one of task queueor task queue. Thus, the logical boundaries depicted inare generally representative of various stages or functional regions of a workflow.

312 302 304 306 308 310 314 316 318 320 324 326 312 328 312 In the illustrated example, task queueis configured to maintain tasks output by one or more of tool, tool, tool, tool, or tool(e.g., for subsequent execution by one or more of tool, tool, tool, tool, or tool). Thus, workflow tools depicted to the left of the first boundaryare upstream tools relative to tasks maintained in the task queue. Similarly, workflow tools depicted to the right of the second boundaryare downstream tools relative to tasks maintained in the task queue.

3 FIG. 322 302 304 306 308 310 314 320 324 330 322 332 324 322 116 122 314 312 322 In the illustrated example of, the task queueis configured to maintain tasks output by one or more of tool, tool, tool, tool, tool, tool, or tool(e.g., for subsequent execution by tool). Thus, workflow tools depicted to the left of the third boundaryare upstream tools relative to tasks maintained in the task queue. Similarly, workflow tools depicted to the right of the fourth boundary(e.g., tool) are downstream tools relative to tasks maintained in the task queue. In this manner, individual tools of a workflow can be regarded as either an upstream toolor a downstream tool, depending on a queued task. For instance, toolis a downstream tool relative to a task maintained in task queueand is an upstream tool relative to a task maintained in task queue.

3 FIG. 124 312 322 312 302 304 306 308 310 322 The workflow structure illustrated inis thus representative of how the described throttling and resuming techniques can be applied in a multi-queue, multi-tool workflow environment. The scheduleris configured to monitor both task queueand task queue, and to further apply different throttling strategies to the respective upstream tools based on the state of each queue and the overall workflow performance. For example, if queuebecomes congested, the scheduler might throttle tools,,,, orselectively, while continuing to allow full operation of tools feeding into queue.

3 FIG. 110 102 302 110 102 112 116 In the context of, each individual tool depicted may represent a complex processing unit capable of parallel execution across multiple coresof the computing system. For instance, a single tool, such as tool, may be configured to utilize up to n coressimultaneously. This parallel processing capability allows a single tool to produce up to n outputs per clock cycle of the computing system, significantly amplifying its task generation or processing capacity. As a result, even workflowsthat appear relatively simple in structure, with only a few upstream tools, can rapidly generate a large volume of tasks.

302 312 314 For example, if toolutilizes all n cores in parallel, it could potentially produce n tasks per clock cycle, quickly populating the task queue. Similarly, downstream tools (e.g., downstream tool) could consume and process multiple tasks simultaneously, potentially at a rate of n tasks per clock cycle. This parallel processing capability at the tool level results in workflows with seemingly few components quickly leading to queue congestion, necessitating the dynamic throttling and resuming mechanisms described herein. The ability of individual workflow tools to leverage multiple compute units (e.g., processor cores) highlights the importance of efficient queue management and task scheduling in maintaining optimal workflow performance, especially in high-performance computing environments where the number of available cores n may be substantial, which is impossible using conventional workflow management techniques.

300 The systemdemonstrates the flexibility and scalability of the workflow management approach, showing how it can handle complex, non-linear task flows with multiple points of potential congestion and varied resource requirements. By applying the throttling and resuming techniques at each queue, the system can maintain optimal performance across the entire workflow, balancing task generation and execution across various stages and branches of the process.

4 FIG. 4 FIG. 400 124 402 404 118 124 406 112 depicts a systemin an example implementation showing operation of the scheduleras selectively throttling and resuming tools during execution of a workflow. Specifically, in the illustrated example of, the workflow includes upstream tool, upstream, task queue, scheduler, and downstream toolto demonstrate a flow of tasks and throttle/resume signals during execution of a workflow.

402 408 408 118 118 408 410 404 412 412 118 118 412 414 408 412 120 116 118 112 4 FIG. To begin, upstream toolgenerates taskand sends taskto task queue. Task queuethen queues taskat block. Similarly, upstream toolgenerates taskand sends taskto task queue. Task queuethen queues taskat block. In the illustrated example, taskand taskare each representative of an example instance of workflow task. In this manner,depicts how multiple upstream toolsare configured to feed tasks (e.g., in parallel, in series, or combinations thereof) into a single task queueduring execution of a workflow.

124 102 118 406 110 408 124 408 406 416 408 406 406 408 418 118 124 118 124 406 118 4 FIG. 4 FIG. The scheduleris configured to monitor system resources (e.g., of computing system) and identify when sufficient resources are available to release a task maintained in task queuefor execution by downstream tool. For instance, in response to detecting that a coreis available to execute task, the schedulerreleases taskfor execution by downstream tool, illustrated inas released queued task. Releasing taskfor execution by the downstream toolcauses the downstream toolto execute task, represented by blockin the illustrated example of. In response to releasing a task from the task queue, the scheduleris further configured to remove an entry in the task queuecorresponding to the released task. In some implementations, the schedulermonitors the downstream toolto determine that the task was successfully executed before removing the task from the task queue.

4 FIG. 112 124 128 420 128 124 116 128 124 402 404 As depicted in the illustrated example of, during execution of the workflow, the schedulerdetects satisfaction of one or more throttle threshold conditions(block). In response to detecting satisfaction of one or more throttle threshold conditions, the scheduleridentifies an upstream toolthat is contributing to satisfaction of the throttle threshold conditions. In one example implementation, the scheduleranalyzes task generation rates of individual upstream tools (e.g., upstream tooland upstream tool) and compares the task generation rates to determine which tool is producing tasks at a disproportionately high rate relative to others.

124 124 118 124 402 404 116 102 124 Alternatively or additionally, the scheduleris configured to examine metadata associated with queued tasks, allowing the schedulerto pinpoint tools contributing most significantly to task queuecongestion. Alternatively or additionally, the schedulerconsiders the computational complexity or resource requirements of tasks generated by upstream tooland upstream tool, prioritizing the identification of an upstream toolproducing resource-intensive tasks that strain computing systemcapabilities. Alternatively or additionally, historical performance data is utilized to identify tools that have previously led to queue overflows (e.g., during prior execution of workflows involving similar tools). Alternatively or additionally, the scheduleris configured to consider the relative importance or priority of different workflow stages, focusing on non-critical path tools when possible, to minimize impact on overall workflow performance.

124 402 404 118 102 124 402 404 124 402 128 422 402 4 FIG. Alternatively or additionally, the scheduleris configured to employ machine learning algorithms to predict whether throttling upstream toolor upstream toolwould most effectively alleviate task queuecongestion based on current workflow patterns and resource availability of computing system. Alternatively or additionally, the scheduleris configured to analyze current system resource utilization associated with operation of upstream tooland upstream tool, respectively, identifying one or more tools consuming excessive resources as potential candidates for throttling. In the illustrated example of, scheduleridentifies upstream toolas being a primary contributor to satisfying the throttle threshold conditionsand issues a throttle commandto the upstream tool.

422 402 402 402 402 402 116 118 404 402 424 118 424 426 124 4 FIG. The throttle commandcauses throttling of the upstream tool, which is representative of pausing operation of upstream toolor reducing a rate at which upstream toolis permitted to generate tasks, allowing upstream toolto continue functioning at a slower pace. While the upstream toolis throttled, implementations permit at least one other upstream toolto continue generating tasks for output to the task queue. For instance, the illustrated example ofdepicts a scenario where upstream toolis permitted to continue generating tasks while upstream toolis throttled, represented by the issuance of taskto task queueand queueing of task(block). Thus, the scheduleris configured to throttle one or more upstream tools independent of (e.g., without) throttling an entirety of the upstream tools relative to a task queue.

402 124 118 406 428 428 406 430 424 402 116 118 428 406 402 118 406 130 While upstream toolis throttled, the schedulercontinues to release tasks from the task queuefor execution by downstream tool, as represented by the released queued taskand subsequent execution of the released queued taskby the downstream tool(block). Although only a single taskis depicted as being generated and queued while the upstream toolis throttled, this illustrated example is not so limiting and any number of upstream toolsmay be permitted to generate any number of tasks for maintenance in task queue, in accordance with the described techniques. Similarly, although only a single released queued taskis depicted as being executed by the downstream toolwhile the upstream toolis throttled, this example is not so limiting and any number of tasks may be released from the task queueand executed by the downstream tooluntil satisfaction of resume threshold conditions.

402 124 130 432 130 124 434 402 402 402 124 402 436 118 112 406 4 FIG. Upstream toolremains throttled until the schedulerdetects satisfaction of resume threshold conditions, represented in the illustrated example ofby block. In response to detecting that one or more resume threshold conditionsare satisfied, the schedulerissues a resume commandto the throttled upstream tool, which represents a degree of “unthrottling” upstream toolfrom its throttled state (e.g., at least partially permitting the upstream toolto resume generating tasks at full capacity and without limitation by the scheduler). Unthrottling of the upstream toolis represented by generation of task, which is sent to the task queue, and execution of the workflowcontinues until all queued tasks have been released for execution by the downstream tool.

124 128 130 112 102 Although described herein in the context of static (e.g., predefined and unchanging) threshold conditions for throttling a workflow tool and resuming a workflow tool, in some implementations the scheduleris configured to dynamically modify at least one of the throttle threshold conditionsor the resume threshold conditionsduring execution of the workflowbased on various factors related to the current state of the computing systemand the workflow itself. This dynamic adjustment allows for more adaptive and efficient management of task generation and execution, particularly in complex or rapidly changing computing environments.

124 128 130 116 124 128 116 124 128 For instance, in some implementations the scheduleris configured to modify at least one of the throttle threshold conditionsor the resume threshold conditionsbased on a number of tools included in the set of upstream tools. For instance, if a number of active upstream tools increases during workflow execution, the scheduleris configured to adjust at least one throttle threshold conditionto a lower value, triggering throttling earlier to prevent queue overflow. Conversely, if some upstream toolscomplete their task generation and become inactive, the scheduleris configured to increase at least one throttle threshold condition, allowing remaining upstream tools to generate tasks more freely.

124 124 128 130 124 128 130 The number of available processing devices, such as processor cores or compute units, may also impact threshold adjustments. For instance, if the schedulerdetects that additional processing resources become available (e.g., due to completion of other workflow tasks, system processes, combinations thereof, and so forth), the schedulermay increase throttle threshold conditionsand reduce resume threshold conditions, allowing for more aggressive task generation and queuing. Conversely, if processing resources become constrained, the scheduleris configured to lower throttle threshold conditionsand increase resume threshold conditionsto maintain system stability and prevent resource exhaustion.

128 130 114 124 124 128 130 Available memory is another critical factor in adjusting one or more of the throttle threshold conditionsor the resume threshold conditions. As available memoryfluctuates during workflow execution, the scheduleris configured to modify threshold conditions accordingly. For example, if memory usage approaches a defined threshold capacity, the scheduleris configurable to reduce one or more throttle threshold conditionsand/or raise one or more resume threshold conditions, effectively creating a larger buffer between the two conditions. This adjustment helps prevent memory overflow while ensuring efficient use of available resources.

124 116 112 116 118 128 130 118 124 128 118 124 128 122 In implementations, the schedulermay also consider the relative position of upstream toolswithin the workflow(e.g., a distance between an upstream tooland a task queue) when adjusting one or more of the throttle threshold conditionsor the resume threshold conditions. For tools that are further “upstream” (i.e., tools that generate tasks which are required to pass through multiple intermediate upstream tools before reaching the task queue), the schedulermay apply more aggressive throttling by lowering one or more of the throttle threshold conditions. This approach helps prevent bottlenecks in complex, multi-stage workflows by managing task generation at earlier stages. Conversely, for upstream tools closer to the task queue, the scheduleris configured to allow higher throttle threshold conditions, enabling more immediate task availability for processing by a downstream tool.

Having considered example systems and techniques for selectively throttling workflow tools, consider now example procedures to illustrate aspects of the techniques described herein.

1 4 FIGS.- The following discussion describes techniques that are configured to be implemented utilizing the systems and devices described herein. Aspects of each of the procedures are configured for implementation in hardware, firmware, software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not limited to the orders shown for performing the operations by the respective blocks. In portions of the following discussion, reference is made to.

5 FIG. 500 502 102 112 116 122 118 112 102 120 116 depicts a procedurein an example implementation of selectively throttling workflow tools during execution of a workflow. To begin, a plurality of workflow tasks are generated by processing data using a plurality of upstream tools included in a workflow (block). The computing system, for instance, receives workflowas including one or more upstream tools (e.g., upstream tool) and one or more downstream tools (e.g., downstream tool) relative to at least one task queue. As part of executing the workflow, the computing systemgenerates at least one workflow taskusing at least one upstream tool.

504 116 120 118 122 120 As part of executing the workflow, the plurality of workflow tasks are queued (block). The upstream tool, for instance, outputs workflow taskto task queuefor buffering until one or more downstream toolsare available to execute the workflow task.

120 118 506 120 506 500 502 116 118 122 While one or more workflow tasksare maintained in the task queue, a determination is made as to whether a corresponding downstream tool is available to execute a queued workflow tasks (block). If no downstream tools are available to execute a queued workflow task(e.g., a “No” determination at block), operation of the procedurereturns to blockand one or more upstream toolscontinue to generate tasks for maintenance in the task queueuntil a corresponding downstream toolis available.

506 508 124 118 102 406 408 408 406 502 502 508 502 504 506 508 112 Alternatively, in response to detecting that a downstream tool is available to execute a queued workflow task (e.g., a “Yes” determination at block), at least one queued workflow task is released for execution by the corresponding available downstream tool (block). The scheduler, for instance, monitors the task queueand hardware resources of the computing systemto identify when the downstream toolis available to execute taskand releases taskto the downstream toolfor execution in response to detecting that sufficient hardware resources are available. Operation then optionally returns to blockto generate and/or execute one or more additional workflow tasks, as indicated by the dashed arrow returning to blockfrom block. In this manner, the procedural flow of block, block, block, and blockcontinues until execution of the workflowis complete.

510 124 118 102 128 112 510 500 116 502 510 During execution of the workflow, both when a downstream tool is available to execute a queued workflow task and when the downstream tool is unavailable to execute the queued workflow task, a determination is made as to whether a throttle threshold is satisfied (block). The scheduler, for instance, monitors the task queueand hardware resource consumption by the computing systemto determine whether one or more throttle threshold conditionsare satisfied during execution of the workflow. If no throttle threshold conditions are satisfied (e.g., a “No” determination at block), operation of procedurecontinues by generating tasks using upstream toolsas part of executing the workflow, represented by the arrow returning to blockfrom block.

510 512 124 402 128 422 402 Alternatively, in response to detecting that at least one throttle threshold condition is satisfied (e.g., a “Yes” determination at block), at least one of the plurality of upstream tools is throttled (block). The scheduler, for instance, identifies upstream toolas contributing to satisfaction of the throttle threshold conditionand issues a throttle commandto the identified upstream tool.

116 514 124 118 102 130 514 500 116 122 508 514 After throttling an upstream tool, a determination is made as to whether a resume threshold is satisfied (block). The scheduler, for instance, continues to monitor the task queueand hardware resource consumption by the computing systemto determine whether one or more resume threshold conditionsare satisfied. If no resume threshold conditions are satisfied (e.g., a “No” determination at block), operation of procedurecontinues by maintaining the throttle on the identified upstream toolwhile releasing queued tasks for execution by available downstream tools, as represented by the arrow returning to blockfrom block.

514 516 124 434 402 402 502 116 Alternatively, in response to detecting that at least one resume threshold condition is satisfied (e.g., a “Yes” determination at block), the throttled upstream tool is resumed (block). The scheduler, for instance, issues a resume commandto the previously throttled upstream tool, allowing the upstream toolto resume normal task generation. Operation then returns to blockto continue generating and executing workflow tasks with upstream toolsoperating at full capacity.

Having described example procedures in accordance with one or more implementations, consider now an example system and device to implement the various techniques described herein.

6 FIG. 600 602 112 118 124 602 illustrates an example systemthat includes an example computing devicethat is representative of one or more computing systems and/or devices that implement the various techniques described herein. This is illustrated through inclusion of the workflow, the task queue, and the scheduler. The computing deviceis configurable, for example, as a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and/or any other suitable computing device or computing system.

602 604 606 608 602 The example computing deviceas illustrated includes a processing device, one or more computer-readable media, and one or more I/O interfacethat are communicatively coupled, one to another. Although not shown, the computing devicefurther includes a system bus or other data and command transfer system that couples the various components, one to another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control and data lines.

604 604 610 610 The processing deviceis representative of functionality to perform one or more operations using hardware. Accordingly, the processing deviceis illustrated as including hardware elementthat is configurable as processors, functional blocks, and so forth. This includes implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elementsare not limited by the materials from which they are formed, or the processing mechanisms employed therein. For example, processors are configurable as semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions are electronically executable instructions.

606 612 604 612 612 612 606 The computer-readable storage mediais illustrated as including memory/storagethat stores instructions that are executable to cause the processing deviceto perform operations. The computer-readable storage medium is configured for storing instructions that, responsive to execution by the processing device, causes the processing device to perform operations. The memory/storagerepresents memory/storage capacity associated with one or more computer-readable media. The memory/storageincludes volatile media (such as random-access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). The memory/storageincludes fixed media (e.g., RAM, ROM, a fixed hard drive, and so on) as well as removable media (e.g., Flash memory, a removable hard drive, an optical disc, and so forth). The computer-readable mediais configurable in a variety of other ways as further described below.

608 602 602 Input/output interface(s)are representative of functionality to allow a user to enter commands and information to computing device, and also allow information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, touch functionality (e.g., capacitive or other sensors that are configured to detect physical touch), a camera (e.g., employing visible or non-visible wavelengths such as infrared frequencies to recognize movement as gestures that do not involve touch), and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, tactile-response device, and so forth. Thus, the computing deviceis configurable in a variety of ways as further described below to support user interaction.

Various techniques are described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. The terms “module,” “functionality,” and “component” as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques are configurable on a variety of commercial computing platforms having a variety of processors.

602 An implementation of the described modules and techniques is stored on or transmitted across some form of computer-readable media. The computer-readable media includes a variety of media that is accessed by the computing device. By way of example, and not limitation, computer-readable media includes “computer-readable storage media” and “computer-readable signal media.”

“Computer-readable storage media” refers to media and/or devices that enable persistent and/or non-transitory storage of information (e.g., instructions are stored thereon that are executable by a processing device) in contrast to mere signal transmission, carrier waves, or signals per se. Thus, computer-readable storage media refers to non-signal bearing media. The computer-readable storage media includes hardware such as volatile and non-volatile, removable and non-removable media and/or storage devices implemented in a method or technology suitable for storage of information such as computer readable instructions, data structures, program modules, logic elements/circuits, or other data. Examples of computer-readable storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage device, tangible media, or article of manufacture suitable to store the desired information and are accessible by a computer.

602 “Computer-readable signal media” refers to a signal-bearing medium that is configured to transmit instructions to the hardware of the computing device, such as via a network. Signal media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier waves, data signals, or other transport mechanism. Signal media also include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

610 606 As previously described, hardware elementsand computer-readable mediaare representative of modules, programmable device logic and/or fixed device logic implemented in a hardware form that are employed in some embodiments to implement at least some aspects of the techniques described herein, such as to perform one or more instructions. Hardware includes components of an integrated circuit or on-chip system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations in silicon or other hardware. In this context, hardware operates as a processing device that performs program tasks defined by instructions and/or logic embodied by the hardware as well as a hardware utilized to store instructions for execution, e.g., the computer-readable storage media described previously.

610 602 602 610 604 602 604 Combinations of the foregoing are also employed to implement various techniques described herein. Accordingly, software, hardware, or executable modules are implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements. The computing deviceis configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of a module that is executable by the computing deviceas software is achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elementsof the processing device. The instructions and/or functions are executable/operable by one or more articles of manufacture (for example, one or more computing devicesand/or processing devices) to implement techniques, modules, and examples described herein.

602 614 616 The techniques described herein are supported by various configurations of the computing deviceand are not limited to the specific examples of the techniques described herein. This functionality is also implementable all or in part through use of a distributed system, such as over a “cloud”via a platformas described below.

614 616 618 616 614 618 602 618 The cloudincludes and/or is representative of a platformfor resources. The platformabstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud. The resourcesinclude applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device. Resourcescan also include services provided over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network.

616 602 616 618 616 600 602 616 614 The platformabstracts resources and functions to connect the computing devicewith other computing devices. The platformalso serves to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the resourcesthat are implemented via the platform. Accordingly, in an interconnected device embodiment, implementation of functionality described herein is distributable throughout the system. For example, the functionality is implementable in part on the computing deviceas well as via the platformthat abstracts the functionality of the cloud.

616 In implementations, the platformemploys a “machine-learning model” that is configured to implement the techniques described herein. A machine-learning model refers to a computer representation that can be tuned (e.g., trained and retrained) based on inputs to approximate unknown functions. In particular, the term machine-learning model can include a model that utilizes algorithms to learn from, and make predictions on, known data by analyzing training data to learn and relearn to generate outputs that reflect patterns and attributes of the training data. Examples of machine-learning models include neural networks, convolutional neural networks (CNNs), long short-term memory (LSTM) neural networks, decision trees, and so forth.

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