On Tue, 2011-01-25 at 12:12 -0800, Tony Luck wrote:

On Tue, Jan 25, 2011 at 9:31 AM, Peter Zijlstra [off-list ref] wrote:

quoted

 struct mmu_gather {
       struct mm_struct        *mm;
       unsigned int            nr;             /* == ~0U => fast mode */
+       unsigned int            max;
       unsigned char           fullmm;         /* non-zero means full mm flush */
       unsigned char           need_flush;     /* really unmapped some PTEs? */
       unsigned long           start_addr;
       unsigned long           end_addr;
-       struct page             *pages[FREE_PTE_NR];
+       struct page             **pages;
+       struct page             *local[8];
 };

Overall it looks OK - builds, boots & runs too. One question about
the above bit ... why "8" elements in the local[] array?  This ought to be
a #define, maybe with a comment explaining the significance. It doesn't
seem to fill out struct mmu_gather to some "nice" size.  I can't think
of why batching 8 at a time (in the fallback cannot allocate **pages case)
is a good number. So is there some science to the choice, or did you
pluck 8 out of the air? 

Yeah, pretty much a random number small enough to make struct mmu_gather
fit on stack, the reason its not 1 is that a few more entries increase
performance a little and freeing more pages increases the chance the
page allocation works next time around.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>