On Mon, Nov 05, 2018 at 11:55:46AM -0500, Daniel Jordan wrote: > +Concept > +======= > + > +ktask is built on unbound workqueues to take advantage of the thread management > +facilities it provides: creation, destruction, flushing, priority setting, and > +NUMA affinity. > + > +A little terminology up front: A 'task' is the total work there is to do and a > +'chunk' is a unit of work given to a thread. So I hate on the task naming. We already have a task, lets not overload that name. > +To complete a task using the ktask framework, a client provides a thread > +function that is responsible for completing one chunk. The thread function is > +defined in a standard way, with start and end arguments that delimit the chunk > +as well as an argument that the client uses to pass data specific to the task. > + > +In addition, the client supplies an object representing the start of the task > +and an iterator function that knows how to advance some number of units in the > +task to yield another object representing the new task position. The framework > +uses the start object and iterator internally to divide the task into chunks. > + > +Finally, the client passes the total task size and a minimum chunk size to > +indicate the minimum amount of work that's appropriate to do in one chunk. The > +sizes are given in task-specific units (e.g. pages, inodes, bytes). The > +framework uses these sizes, along with the number of online CPUs and an > +internal maximum number of threads, to decide how many threads to start and how > +many chunks to divide the task into. > + > +For example, consider the task of clearing a gigantic page. This used to be > +done in a single thread with a for loop that calls a page clearing function for > +each constituent base page. To parallelize with ktask, the client first moves > +the for loop to the thread function, adapting it to operate on the range passed > +to the function. In this simple case, the thread function's start and end > +arguments are just addresses delimiting the portion of the gigantic page to > +clear. Then, where the for loop used to be, the client calls into ktask with > +the start address of the gigantic page, the total size of the gigantic page, > +and the thread function. Internally, ktask will divide the address range into > +an appropriate number of chunks and start an appropriate number of threads to > +complete these chunks. I see no mention of padata anywhere; I also don't see mention of the async init stuff. Both appear to me to share, at least in part, the same reason for existence. > +Scheduler Interaction > +===================== > + > +Even within the resource limits, ktask must take care to run a number of > +threads appropriate for the system's current CPU load. Under high CPU usage, > +starting excessive helper threads may disturb other tasks, unfairly taking CPU > +time away from them for the sake of an optimized kernel code path. > + > +ktask plays nicely in this case by setting helper threads to the lowest > +scheduling priority on the system (MAX_NICE). This way, helpers' CPU time is > +appropriately throttled on a busy system and other tasks are not disturbed. > + > +The main thread initiating the task remains at its original priority so that it > +still makes progress on a busy system. > + > +It is possible for a helper thread to start running and then be forced off-CPU > +by a higher priority thread. With the helper's CPU time curtailed by MAX_NICE, > +the main thread may wait longer for the task to finish than it would have had > +it not started any helpers, so to ensure forward progress at a single-threaded > +pace, once the main thread is finished with all outstanding work in the task, > +the main thread wills its priority to one helper thread at a time. At least > +one thread will then always be running at the priority of the calling thread. What isn't clear is if this calling thread is waiting or not. Only do this inheritance trick if it is actually waiting on the work. If it is not, nobody cares. > +Cgroup Awareness > +================ > + > +Given the potentially large amount of CPU time ktask threads may consume, they > +should be aware of the cgroup of the task that called into ktask and > +appropriately throttled. > + > +TODO: Implement cgroup-awareness in unbound workqueues. Yes.. that needs done. > +Power Management > +================ > + > +Starting additional helper threads may cause the system to consume more energy, > +which is undesirable on energy-conscious devices. Therefore ktask needs to be > +aware of cpufreq policies and scaling governors. > + > +If an energy-conscious policy is in use (e.g. powersave, conservative) on any > +part of the system, that is a signal that the user has strong power management > +preferences, in which case ktask is disabled. > + > +TODO: Implement this. No, don't do that, its broken. Also, we're trying to move to a single cpufreq governor for all. Sure we'll retain 'performance', but powersave and conservative and all that nonsense should go away eventually. That's not saying you don't need a knob for this; but don't look at cpufreq for this.
