On Wed, Aug 02, 2023 at 06:32:51PM +0300, Mike Rapoport wrote: > > +/* > > + * We have several different "preferred sizes" for the nodemask > > + * operations, depending on operation. > > + * > > + * For example, the bitmap scanning and operating operations have > > + * optimized routines that work for the single-word case, but only when > > + * the size is constant. So if NR_CPUS fits in one single word, we are > > ^ MAX_NUMNODES? > > > + * better off using that small constant, in order to trigger the > > + * optimized bit finding. That is 'small_nodemask_size'. > > + * > > + * The clearing and copying operations will similarly perform better > > + * with a constant size, but we limit that size arbitrarily to four > > + * words. We call this 'large_nodemask_size'. > > + * > > + * Finally, some operations just want the exact limit, either because > > + * they set bits or just don't have any faster fixed-sized versions. We > > + * call this just 'nr_nodemask_bits'. > > + * > > + * Note that these optional constants are always guaranteed to be at > > + * least as big as 'nr_node_ids' itself is, and all our nodemask > > + * allocations are at least that size (see nodemask_size()). The > > We don't have nodemask_size(). NODEMASK_ALLOC() actually allocates memory > only when NODE_SHIFT > 8 and it always uses the static size. > > > + * optimization comes from being able to potentially use a compile-time > > + * constant instead of a run-time generated exact number of CPUs. > > ^ nodes? Durr, clearly I didn't actually read the comment after I 'borrowed' it and regex'ed it into 'shape'. I'll go fix, thanks!
