Re: Plumbers 2018 - Performance and Scalability Microconference

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/8/18 12:13 AM, John Hubbard wrote:
I'm interested in the first 3 of those 4 topics, so if it doesn't conflict with HMM topics or
fix-gup-with-dma topics, I'd like to attend.

Great, we'll add your name to the list.

GPUs generally need to access large chunks of
memory, and that includes migrating (dma-copying) pages around.

So for example a multi-threaded migration of huge pages between normal RAM and GPU memory is an
intriguing direction (and I realize that it's a well-known topic, already). Doing that properly
(how many threads to use?) seems like it requires scheduler interaction.

Yes, in past discussions of multithreading kernel work, there's been some discussion of a scheduler API that could answer "are there idle CPUs we could use to multithread?".

Instead of adding an interface, though, we could just let the scheduler do something it already knows how to do: prioritize.

Additional threads used to parallelize kernel work could run at the lowest priority (i.e. MAX_NICE).  If the machine is heavily loaded, these extra threads simply won't run and other workloads on the system will be unaffected.

There's the issue of priority inversion if one or more of those extra threads get started and are then preempted by normal-priority tasks midway through, but the main thread doing the job can just will its priority to each worker in turn once it's finished, so at most one thread will be active on a heavily loaded system, again leaving other workloads on the system undisturbed.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux