| Message ID | 20210808235018.1924918-2-jhubbard@nvidia.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | A few gup refactorings and documentation updates | expand |
On Sun, Aug 08, 2021 at 04:50:16PM -0700, John Hubbard wrote: > @@ -103,8 +103,14 @@ static inline struct page *try_get_compound_head(struct page *page, int refs) > * same time. (That's true throughout the get_user_pages*() and > * pin_user_pages*() APIs.) Cases: > * > - * FOLL_GET: page's refcount will be incremented by 1. > - * FOLL_PIN: page's refcount will be incremented by GUP_PIN_COUNTING_BIAS. > + * FOLL_GET: page's refcount will be incremented by refs. I think this would read more clearly if it said @refs (throughout). > + * > + * FOLL_PIN on compound pages that are > two pages long: page's refcount will > + * be incremented by refs, and page[2].hpage_pinned_refcount will be > + * incremented by refs * GUP_PIN_COUNTING_BIAS. > + * > + * FOLL_PIN on normal pages, or compound pages that are two pages long: > + * page's refcount will be incremented by refs * GUP_PIN_COUNTING_BIAS. > * > * Return: head page (with refcount appropriately incremented) for success, or > * NULL upon failure. If neither FOLL_GET nor FOLL_PIN was set, that's Did you run 'make htmldocs' and see how it renders? I haven't looked, but this might work better as an rst list?
On 8/8/21 6:39 PM, Matthew Wilcox wrote: > On Sun, Aug 08, 2021 at 04:50:16PM -0700, John Hubbard wrote: >> @@ -103,8 +103,14 @@ static inline struct page *try_get_compound_head(struct page *page, int refs) >> * same time. (That's true throughout the get_user_pages*() and >> * pin_user_pages*() APIs.) Cases: >> * >> - * FOLL_GET: page's refcount will be incremented by 1. >> - * FOLL_PIN: page's refcount will be incremented by GUP_PIN_COUNTING_BIAS. >> + * FOLL_GET: page's refcount will be incremented by refs. > > I think this would read more clearly if it said @refs (throughout). OK, will change that for v2. > >> + * >> + * FOLL_PIN on compound pages that are > two pages long: page's refcount will >> + * be incremented by refs, and page[2].hpage_pinned_refcount will be >> + * incremented by refs * GUP_PIN_COUNTING_BIAS. >> + * >> + * FOLL_PIN on normal pages, or compound pages that are two pages long: >> + * page's refcount will be incremented by refs * GUP_PIN_COUNTING_BIAS. >> * >> * Return: head page (with refcount appropriately incremented) for success, or >> * NULL upon failure. If neither FOLL_GET nor FOLL_PIN was set, that's > > Did you run 'make htmldocs' and see how it renders? I haven't looked, > but this might work better as an rst list? > Hadn't occurred to me, due to my own incorrect mental separation between comment kernel docs, and rst formatting ("rst == Documentation/"). I'll give it a try. thanks,
On 8/8/21 6:39 PM, Matthew Wilcox wrote: ... >> + * FOLL_PIN on compound pages that are > two pages long: page's refcount will >> + * be incremented by refs, and page[2].hpage_pinned_refcount will be >> + * incremented by refs * GUP_PIN_COUNTING_BIAS. >> + * >> + * FOLL_PIN on normal pages, or compound pages that are two pages long: >> + * page's refcount will be incremented by refs * GUP_PIN_COUNTING_BIAS. >> * >> * Return: head page (with refcount appropriately incremented) for success, or >> * NULL upon failure. If neither FOLL_GET nor FOLL_PIN was set, that's > > Did you run 'make htmldocs' and see how it renders? I haven't looked, > but this might work better as an rst list? > OK, after a certain amount of sphinx and sphinx-extension-related unhappiness, I can finally report, "nope, rst lists do not help here". That's because the rendered kerneldoc HTML versions of non-numbered lists look identical to paragraphs that are not lists. And the numbered lists either look identical (if you used the "1." format), or different in a way that hurts the source code (if you used the "#." format). And the lists are also fussier to maintain, because if you do not *exactly* line up the second and following lines in a paragraph, then HTML version of the list breaks. Whereas, the HTML looks fine either way if it is not a list. I probably shouldn't mention that the only function in gup.c that is listed as "make this show up in the docs" is get_user_pages_fast(), because that might lead to people asking to add more items to the :functions: list in mm-api.rst. And then I'd have to explain that the kerneldoc rendered output for functions is still mostly useless: kernel developers need to see the implementation as well; non-kernel developers will find it incomplete and cryptic; and it's hard to read for anyone, due to being spread over a country mile's worth of whitespace. So I won't bring that up. :) thanks,
diff --git a/mm/gup.c b/mm/gup.c index 77150624f77a..5cb18b62921c 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -103,8 +103,14 @@ static inline struct page *try_get_compound_head(struct page *page, int refs) * same time. (That's true throughout the get_user_pages*() and * pin_user_pages*() APIs.) Cases: * - * FOLL_GET: page's refcount will be incremented by 1. - * FOLL_PIN: page's refcount will be incremented by GUP_PIN_COUNTING_BIAS. + * FOLL_GET: page's refcount will be incremented by refs. + * + * FOLL_PIN on compound pages that are > two pages long: page's refcount will + * be incremented by refs, and page[2].hpage_pinned_refcount will be + * incremented by refs * GUP_PIN_COUNTING_BIAS. + * + * FOLL_PIN on normal pages, or compound pages that are two pages long: + * page's refcount will be incremented by refs * GUP_PIN_COUNTING_BIAS. * * Return: head page (with refcount appropriately incremented) for success, or * NULL upon failure. If neither FOLL_GET nor FOLL_PIN was set, that's @@ -143,6 +149,8 @@ __maybe_unused struct page *try_grab_compound_head(struct page *page, * * However, be sure to *also* increment the normal page refcount * field at least once, so that the page really is pinned. + * That's why the refcount from the earlier + * try_get_compound_head() is left intact. */ if (hpage_pincount_available(page)) hpage_pincount_add(page, refs); @@ -186,10 +194,8 @@ static void put_compound_head(struct page *page, int refs, unsigned int flags) * @flags: gup flags: these are the FOLL_* flag values. * * Either FOLL_PIN or FOLL_GET (or neither) may be set, but not both at the same - * time. Cases: - * - * FOLL_GET: page's refcount will be incremented by 1. - * FOLL_PIN: page's refcount will be incremented by GUP_PIN_COUNTING_BIAS. + * time. Cases: please see the try_grab_compound_head() documentation, with + * "refs=1". * * Return: true for success, or if no action was required (if neither FOLL_PIN * nor FOLL_GET was set, nothing is done). False for failure: FOLL_GET or
The documentation for try_grab_compound_head() and try_grab_page() has fallen a little out of date. Update and clarify a few points. Signed-off-by: John Hubbard <jhubbard@nvidia.com> --- mm/gup.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)