[1/4] padata: update documentation

Commit Message

Daniel Jordan Nov. 20, 2019, 6:54 p.m. UTC

Remove references to unused functions and update to reflect the new
struct padata_shell.

Fixes: 815613da6a67 ("kernel/padata.c: removed unused code")
Signed-off-by: Daniel Jordan <[e-mail]>
Cc: Eric Biggers <[e-mail]>
Cc: Herbert Xu <[e-mail]>
Cc: Jonathan Corbet <[e-mail]>
Cc: Steffen Klassert <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
---
 Documentation/padata.txt | 50 +++++++++++++++++++++-------------------
 1 file changed, 26 insertions(+), 24 deletions(-)

Comments

Jonathan Corbet Nov. 20, 2019, 7:16 p.m. UTC | #1

On Wed, 20 Nov 2019 13:54:09 -0500
Daniel Jordan <[e-mail]> wrote:

> Remove references to unused functions and update to reflect the new
> struct padata_shell.
> 
> Fixes: 815613da6a67 ("kernel/padata.c: removed unused code")
> Signed-off-by: Daniel Jordan <[e-mail]>
> Cc: Eric Biggers <[e-mail]>
> Cc: Herbert Xu <[e-mail]>
> Cc: Jonathan Corbet <[e-mail]>
> Cc: Steffen Klassert <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> ---
>  Documentation/padata.txt | 50 +++++++++++++++++++++-------------------
>  1 file changed, 26 insertions(+), 24 deletions(-)

This all seems fine - it's better than not doing it - but can I put in a
request or two?

 - This document is already formatted as RST, and your changes continue
   that.  Can we please move it to Documentation/core-api/padata.rst and
   add it to the TOC tree there?  Then it can become part of our formatted
   docs.

 - The padata code seems to be nicely equipped with kerneldoc comments; it
   would be awfully nice to pull them into the document directly rather
   than replicating the API there.  (Why does the document do that now?
   Blame the bozo who originally wrote it :)  That would make the document
   more complete and easier to maintain going forward.

For added goodness we could stick in an SPDX tag while we're at it.

Thanks,

jon

Daniel Jordan Nov. 21, 2019, 2:36 p.m. UTC | #2

On Wed, Nov 20, 2019 at 12:16:34PM -0700, Jonathan Corbet wrote:
> This all seems fine - it's better than not doing it - but can I put in a
> request or two?
> 
>  - This document is already formatted as RST, and your changes continue
>    that.  Can we please move it to Documentation/core-api/padata.rst and
>    add it to the TOC tree there?  Then it can become part of our formatted
>    docs.
> 
>  - The padata code seems to be nicely equipped with kerneldoc comments; it
>    would be awfully nice to pull them into the document directly rather
>    than replicating the API there.  (Why does the document do that now?
>    Blame the bozo who originally wrote it :)  That would make the document
>    more complete and easier to maintain going forward.

Ok.  It would be nice to preserve the how-to aspect of the original doc as
well, in other words, the order the interfaces should be called in.  Will do
both.

> For added goodness we could stick in an SPDX tag while we're at it.

I'll use the license from padata.c/h.

Patch

diff --git a/Documentation/padata.txt b/Documentation/padata.txt
index b37ba1eaace3..a03afb1588f9 100644
--- a/Documentation/padata.txt
+++ b/Documentation/padata.txt
@@ -2,7 +2,7 @@ 
 The padata parallel execution mechanism
 =======================================
 
-:Last updated: for 2.6.36
+:Last updated: for 5.4
 
 Padata is a mechanism by which the kernel can farm work out to be done in
 parallel on multiple CPUs while retaining the ordering of tasks.  It was
@@ -53,27 +53,26 @@  padata cpumask contains no active CPU (flag not set).
 padata_stop clears the flag and blocks until the padata instance
 is unused.
 
-The list of CPUs to be used can be adjusted with these functions::
+Finally, complete padata initialization by allocating a padata_shell object::
+
+   struct padata_shell *padata_alloc_shell(struct padata_instance *pinst);
+
+A padata_shell is used to submit a job to padata and allows a series of such
+jobs to be serialized independently.  A padata_instance may have one or more
+padata_shell objects associated with it, each allowing a separate series of
+jobs.
+
+The list of CPUs to be used can be adjusted with this function::
 
-    int padata_set_cpumasks(struct padata_instance *pinst,
-			    cpumask_var_t pcpumask,
-			    cpumask_var_t cbcpumask);
     int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type,
 			   cpumask_var_t cpumask);
-    int padata_add_cpu(struct padata_instance *pinst, int cpu, int mask);
-    int padata_remove_cpu(struct padata_instance *pinst, int cpu, int mask);
 
 Changing the CPU masks are expensive operations, though, so it should not be
 done with great frequency.
 
-It's possible to change both cpumasks of a padata instance with
-padata_set_cpumasks by specifying the cpumasks for parallel execution (pcpumask)
-and for the serial callback function (cbcpumask). padata_set_cpumask is used to
-change just one of the cpumasks. Here cpumask_type is one of PADATA_CPU_SERIAL,
-PADATA_CPU_PARALLEL and cpumask specifies the new cpumask to use.
-To simply add or remove one CPU from a certain cpumask the functions
-padata_add_cpu/padata_remove_cpu are used. cpu specifies the CPU to add or
-remove and mask is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL.
+padata_set_cpumask is used to change just one of the cpumasks. Here cpumask_type
+is one of PADATA_CPU_SERIAL or PADATA_CPU_PARALLEL, and cpumask specifies the
+new cpumask to use.
 
 If a user is interested in padata cpumask changes, he can register to
 the padata cpumask change notifier::
@@ -117,12 +116,13 @@  momentarily.
 
 The submission of work is done with::
 
-    int padata_do_parallel(struct padata_instance *pinst,
-		           struct padata_priv *padata, int cb_cpu);
+    int padata_do_parallel(struct padata_shell *ps,
+		           struct padata_priv *padata, int *cb_cpu);
 
-The pinst and padata structures must be set up as described above; cb_cpu
-specifies which CPU will be used for the final callback when the work is
-done; it must be in the current instance's CPU mask.  The return value from
+The ps and padata structures must be set up as described above; cb_cpu
+points to the preferred CPU to be used for the final callback when the work is
+done; it must be in the current instance's CPU mask (if not the cb_cpu pointer
+is updated to point to the CPU actually chosen).  The return value from
 padata_do_parallel() is zero on success, indicating that the work is in
 progress. -EBUSY means that somebody, somewhere else is messing with the
 instance's CPU mask, while -EINVAL is a complaint about cb_cpu not being
@@ -154,10 +154,12 @@  Note that this call may be deferred for a while since the padata code takes
 pains to ensure that tasks are completed in the order in which they were
 submitted.
 
-The one remaining function in the padata API should be called to clean up
-when a padata instance is no longer needed::
+Cleaning up a padata instance predictably involves calling the three free
+functions that correspond to the allocation in reverse:
 
+    void padata_free_shell(struct padata_shell *ps);
+    void padata_stop(struct padata_instance *pinst);
     void padata_free(struct padata_instance *pinst);
 
-This function will busy-wait while any remaining tasks are completed, so it
-might be best not to call it while there is work outstanding.
+It is the user's responsibility to ensure all outstanding jobs are complete
+before any of the above are called.