From: Peter Zijlstra <email@example.com> To: Daniel Jordan <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Pavel.Tatashin@microsoft.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, "Rafael J. Wysocki" <firstname.lastname@example.org> Subject: Re: [RFC PATCH v4 01/13] ktask: add documentation Date: Tue, 6 Nov 2018 09:49:11 +0100 Message-ID: <20181106084911.GA22504@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <email@example.com> 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.
next prev parent reply index Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-05 16:55 [RFC PATCH v4 00/13] ktask: multithread CPU-intensive kernel work Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 01/13] ktask: add documentation Daniel Jordan 2018-11-05 21:19 ` Randy Dunlap 2018-11-06 2:27 ` Daniel Jordan 2018-11-06 8:49 ` Peter Zijlstra [this message] 2018-11-06 20:34 ` Daniel Jordan 2018-11-06 20:51 ` Jason Gunthorpe 2018-11-07 10:27 ` Peter Zijlstra 2018-11-07 20:21 ` Daniel Jordan 2018-11-07 10:35 ` Peter Zijlstra 2018-11-07 21:20 ` Daniel Jordan 2018-11-08 17:26 ` Jonathan Corbet 2018-11-08 19:15 ` Daniel Jordan 2018-11-08 19:24 ` Jonathan Corbet 2018-11-27 19:50 ` Pavel Machek 2018-11-28 16:56 ` Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 02/13] ktask: multithread CPU-intensive kernel work Daniel Jordan 2018-11-05 20:51 ` Randy Dunlap 2018-11-06 2:24 ` Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 03/13] ktask: add undo support Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 04/13] ktask: run helper threads at MAX_NICE Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 05/13] workqueue, ktask: renice helper threads to prevent starvation Daniel Jordan 2018-11-13 16:34 ` Tejun Heo 2018-11-19 16:45 ` Daniel Jordan 2018-11-20 16:33 ` Tejun Heo 2018-11-20 17:03 ` Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 06/13] vfio: parallelize vfio_pin_map_dma Daniel Jordan 2018-11-05 21:51 ` Alex Williamson 2018-11-06 2:42 ` Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 07/13] mm: change locked_vm's type from unsigned long to atomic_long_t Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 08/13] vfio: remove unnecessary mmap_sem writer acquisition around locked_vm Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 09/13] vfio: relieve mmap_sem reader cacheline bouncing by holding it longer Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 10/13] mm: enlarge type of offset argument in mem_map_offset and mem_map_next Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 11/13] mm: parallelize deferred struct page initialization within each node Daniel Jordan 2018-11-10 3:48 ` Elliott, Robert (Persistent Memory) 2018-11-12 16:54 ` Daniel Jordan 2018-11-12 22:15 ` Elliott, Robert (Persistent Memory) 2018-11-19 16:01 ` Daniel Jordan 2018-11-27 0:12 ` Elliott, Robert (Persistent Memory) 2018-11-27 20:23 ` Daniel Jordan 2018-11-19 16:29 ` Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 12/13] mm: parallelize clear_gigantic_page Daniel Jordan 2018-11-05 16:55 ` [RFC PATCH v4 13/13] hugetlbfs: parallelize hugetlbfs_fallocate with ktask Daniel Jordan 2018-11-05 17:29 ` [RFC PATCH v4 00/13] ktask: multithread CPU-intensive kernel work Michal Hocko 2018-11-06 1:29 ` Daniel Jordan 2018-11-06 9:21 ` Michal Hocko 2018-11-07 20:17 ` Daniel Jordan 2018-11-05 18:49 ` Zi Yan 2018-11-06 2:20 ` Daniel Jordan 2018-11-06 2:48 ` Zi Yan 2018-11-06 19:00 ` Daniel Jordan 2018-11-30 19:18 ` Tejun Heo 2018-12-01 0:13 ` Daniel Jordan 2018-12-03 16:16 ` Tejun Heo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181106084911.GA22504@hirez.programming.kicks-ass.net \ --firstname.lastname@example.org \ --cc=Pavel.Tatashin@microsoft.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
KVM Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \ firstname.lastname@example.org public-inbox-index kvm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.kvm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git