2.4.23-pre7 vmscan.c typo
Subsystems (3)
PATCH 1/1 2.4.23-pre7 vmscan.c typo
The following appears to be a typo in mm/vmscan.c
Thanks,
Shantanu
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
vmscan.c renamed from vmscan.c.~1~ +1 -1
@@ -596,7 +596,7 @@continue ; } - nr_pages--; + ratio--;del_page_from_active_list (page);add_page_to_inactive_list (page);
Quoted 3 lines · Shantanu Goel
The following appears to be a typo in
mm/vmscan.c
It sure is. Scary.
mm/vmscan.c +1 -1
@@ -596,7 +596,7 @@continue ; } - nr_pages--; + ratio--;del_page_from_active_list (page);add_page_to_inactive_list (page);
I note that `ratio' here is the number of pages which we try to deactivate rather than the number of pages which we scan. Is this intentional?
Quoted 6 lines · Andrew Morton
Quoted 3 lines · Shantanu Goel
The following appears to be a typo in
mm/vmscan.cIt sure is. Scary.
indeed, great spotting.
Quoted 15 lines
mm/vmscan.c +1
-1@@ -596,7 +596,7 @@continue ; } - nr_pages--; + ratio--;del_page_from_active_list (page);add_page_to_inactive_list (page);
Quoted 2 lines
I note that `ratio' here is the number of pages which we try to deactivate rather than the number of pages which we scan. Is this intentional?
yes, it's intentional, this ensures we refile a number of pages and that we don't only roll the list, it won't loop forever since at the second pass the referenced bit will be clear.
BTW, the above obviously correct patch was apparently due an half merge error too, this is what my 2.4.22aa1 or alternatively 2.4.23pre6aa3 looks like in this area. This gets right the highmem case too, so that we ensure to refile normal zone if the user is GFP_KERNEL and we don't deactivate highmem unless it's worthwhile, and it has the bh-related knwoledge, so over time it'd be better to merge these bits too.
thanks,
static void refill_inactive(int nr_pages, zone_t * classzone)
{
struct list_head * entry;
unsigned long ratio;
ratio = (unsigned long) nr_pages * classzone->nr_active_pages / (((unsigned long) classzone->nr_inactive_pages * vm_lru_balance_ratio) + 1);
entry = active_list.prev;
while (ratio && entry != &active_list) {
struct page * page;
int related_metadata = 0;
page = list_entry(entry, struct page, lru);
entry = entry->prev;
if (!memclass(page_zone(page), classzone)) {
/*
* Hack to address an issue found by Rik. The problem is that
* highmem pages can hold buffer headers allocated
* from the slab on lowmem, and so if we are working
* on the NORMAL classzone here, it is correct not to
* try to free the highmem pages themself (that would be useless)
* but we must make sure to drop any lowmem metadata related to those
* highmem pages.
*/
if (page->buffers && page->mapping) { /* fast path racy check */
if (unlikely(TryLockPage(page)))
continue;
if (page->buffers && page->mapping && memclass_related_bhs(page, classzone)) /* non racy check */
related_metadata = 1;
UnlockPage(page);
}
if (!related_metadata)
continue;
}
if (PageTestandClearReferenced(page)) {
list_del(&page->lru);
list_add(&page->lru, &active_list);
continue;
}
if (!related_metadata)
ratio--;
del_page_from_active_list(page);
add_page_to_inactive_list(page);
SetPageReferenced(page);
}
if (entry != &active_list) {
list_del(&active_list);
list_add(&active_list, entry);
}
}Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/
Quoted 32 lines · Andrea Arcangeli
Quoted 6 lines · Andrew Morton
Quoted 3 lines · Shantanu Goel
The following appears to be a typo in
mm/vmscan.cIt sure is. Scary.
indeed, great spotting.
Quoted 15 lines
mm/vmscan.c +1
-1@@ -596,7 +596,7 @@continue ; } - nr_pages--; + ratio--;del_page_from_active_list (page);add_page_to_inactive_list (page);Quoted 2 lines
I note that `ratio' here is the number of pages which we try to deactivate rather than the number of pages which we scan. Is this intentional?
yes, it's intentional, this ensures we refile a number of pages and that we don't only roll the list, it won't loop forever since at the second pass the referenced bit will be clear.
Quoted 3 lines
BTW, the above obviously correct patch was apparently due an half merge error too, this is what my 2.4.22aa1 or alternatively 2.4.23pre6aa3 looks like in this area.
Fixed. Thanks Shantanu.
It must have been a merge error. :(
Quoted 4 lines
This gets right the highmem case too, so that we ensure to refile normal zone if the user is
GFP_KERNELand we don't deactivate highmem unless it's worthwhile, and it has the bh-related knwoledge, so over time it'd be better to merge these bits too.
Will take a look into this...