On Mon, Apr 15, 2024 at 09:19:39PM +0800, Yunsheng Lin wrote: > +API interface > +============= > +As the design and implementation of page_frag API, the allocation side does not "... implies, the allocation side ..." > +allow concurrent calling, it is assumed that the caller must ensure there is not "... . Instead, it is assumed that ...: > +concurrent alloc calling to the same page_frag_cache instance by using it's own "... by using its own ..." > +lock or rely on some lockless guarantee like NAPI softirq. > + > +Depending on different use cases, callers expecting to deal with va, page or > +both va and page for them may call page_frag_alloc_va*, page_frag_alloc_pg*, > +or page_frag_alloc* API accordingly. > + > +There is also a use case that need minimum memory in order for forward > +progressing, but can do better if there is more memory available. Introduce Did you mean "... but more performant if more memory is available"? > +page_frag_alloc_prepare() and page_frag_alloc_commit() related API, the caller s/Introduce/Using/ > +requests the minimum memory it need and the prepare API will return the maximum > +size of the fragment returned, caller need to report back to the page_frag core "The caller needs to either call the commit API ..." > +how much memory it actually use by calling commit API, or not calling the commit "... to report how much memory it actually uses ..." > +API if deciding to not use any memory. "... or not do so if deciding to not use any memory." Thanks. -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature