On Sun, Feb 03, 2019 at 09:21:33PM -0800, [email protected] wrote: > +/* > + * GUP_PIN_COUNTING_BIAS, and the associated functions that use it, overload > + * the page's refcount so that two separate items are tracked: the original > page > + * reference count, and also a new count of how many get_user_pages() calls > were > + * made against the page. ("gup-pinned" is another term for the latter). > + * > + * With this scheme, get_user_pages() becomes special: such pages are marked > + * as distinct from normal pages. As such, the new put_user_page() call (and > + * its variants) must be used in order to release gup-pinned pages. > + * > + * Choice of value: > + * > + * By making GUP_PIN_COUNTING_BIAS a power of two, debugging of page > reference > + * counts with respect to get_user_pages() and put_user_page() becomes > simpler, > + * due to the fact that adding an even power of two to the page refcount has > + * the effect of using only the upper N bits, for the code that counts up > using > + * the bias value. This means that the lower bits are left for the exclusive > + * use of the original code that increments and decrements by one (or at > least, > + * by much smaller values than the bias value). > + * > + * Of course, once the lower bits overflow into the upper bits (and this is > + * OK, because subtraction recovers the original values), then visual > inspection > + * no longer suffices to directly view the separate counts. However, for > normal > + * applications that don't have huge page reference counts, this won't be an > + * issue. > + * > + * This has to work on 32-bit as well as 64-bit systems. In the more > constrained > + * 32-bit systems, the 10 bit value of the bias value leaves 22 bits for the > + * upper bits. Therefore, only about 4M calls to get_user_page() may occur > for > + * a page.
The refcount is 32-bit on both 64 and 32 bit systems. This limit exists on both sizes of system.
