[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181127195008.GA20692@amd>
Date: Tue, 27 Nov 2018 20:50:08 +0100
From: Pavel Machek <pavel@....cz>
To: Daniel Jordan <daniel.m.jordan@...cle.com>
Cc: linux-mm@...ck.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, aarcange@...hat.com,
aaron.lu@...el.com, akpm@...ux-foundation.org,
alex.williamson@...hat.com, bsd@...hat.com,
darrick.wong@...cle.com, dave.hansen@...ux.intel.com,
jgg@...lanox.com, jwadams@...gle.com, jiangshanlai@...il.com,
mhocko@...nel.org, mike.kravetz@...cle.com,
Pavel.Tatashin@...rosoft.com, prasad.singamsetty@...cle.com,
rdunlap@...radead.org, steven.sistare@...cle.com,
tim.c.chen@...el.com, tj@...nel.org, vbabka@...e.cz
Subject: Re: [RFC PATCH v4 01/13] ktask: add documentation
Hi!
> Motivates and explains the ktask API for kernel clients.
>
> Signed-off-by: Daniel Jordan <daniel.m.jordan@...cle.com>
> ---
> Documentation/core-api/index.rst | 1 +
> Documentation/core-api/ktask.rst | 213 +++++++++++++++++++++++++++++++
> 2 files changed, 214 insertions(+)
> create mode 100644 Documentation/core-api/ktask.rst
>
> diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
> index 3adee82be311..c143a280a5b1 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -18,6 +18,7 @@ Core utilities
> refcount-vs-atomic
> cpu_hotplug
> idr
> + ktask
> local_ops
> workqueue
> genericirq
> diff --git a/Documentation/core-api/ktask.rst b/Documentation/core-api/ktask.rst
> new file mode 100644
> index 000000000000..c3c00e1f802f
> --- /dev/null
> +++ b/Documentation/core-api/ktask.rst
> @@ -0,0 +1,213 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +============================================
> +ktask: parallelize CPU-intensive kernel work
> +============================================
> +
> +:Date: November, 2018
> +:Author: Daniel Jordan <daniel.m.jordan@...cle.com>
> +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.
Great, so my little task is bound to CPUs 1-4 and uses gigantic
pages. Kernel clears them for me.
a) Do all the CPUs work for me, or just CPUs I was assigned to?
b) Will my time my_little_task show the system time including the
worker threads?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists