Re: [patch-2.4.0-test10-pre3] logic of __alloc_pages_limit(
On Mon, 16 Oct 2000, Petr Vandrovec wrote:
> On 16 Oct 00 at 22:50, Tigran Aivazian wrote:
> > + 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;
> > + }
>
> Old code returned page from both reclaim_page() or rmqueue(), while new
> returns pages only from rmqueue... What happens with page grabbed by
> rmqueue, BTW ? Or is there something out of picture I do not see?
> Petr
You are absolutely right, sorry. I will keep my eyes open a bit wider next
time. I put back Linus and linux-kernel to admit my mistake.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test10-pre3] logic of __alloc_pages_limit().
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.cMon 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test10-pre3] logic of __alloc_pages_limit().
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.cMon 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test10-pre3] logic of __alloc_pages_limit(
On Mon, 16 Oct 2000, Petr Vandrovec wrote:
On 16 Oct 00 at 22:50, Tigran Aivazian wrote:
+ 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;
+ }
Old code returned page from both reclaim_page() or rmqueue(), while new
returns pages only from rmqueue... What happens with page grabbed by
rmqueue, BTW ? Or is there something out of picture I do not see?
Petr
You are absolutely right, sorry. I will keep my eyes open a bit wider next
time. I put back Linus and linux-kernel to admit my mistake.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
