Hi Linus and Rik,
The same analysis I did for __alloc_pages() applies to
__alloc_pages_limit(), namely it can be optimized by looking at the logic
of 'page == NULL'. In both cases, of course, I checked the assembly
listing to make sure that my patch didn't make a worse code. It was always
a few instructions shorter and therefore worth it. (I didn't check whether
gcc produced fewer branches, I assume he did, otherwise he would be
totally braindead...).
Regards,
Tigran
--- linux/mm/page_alloc.c Sun Oct 15 20:40:38 2000
+++ work/mm/page_alloc.c Mon Oct 16 22:39:13 2000
@@ -262,15 +262,17 @@
}
if (z->free_pages + z->inactive_clean_pages >= water_mark) {
- struct page *page = NULL;
+ struct page *page;
/* If possible, reclaim a page directly. */
- if (direct_reclaim && z->free_pages < z->pages_min + 8)
+ if (direct_reclaim && z->free_pages < z->pages_min + 8) {
page = reclaim_page(z);
- /* If that fails, fall back to rmqueue. */
- if (!page)
- page = rmqueue(z, order);
- if (page)
- return page;
+ /* If that fails, fall back to rmqueue. */
+ if (!page) {
+ page = rmqueue(z, order);
+ if (page)
+ return page;
+ }
+ }
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:10 EST