On Thu 23-08-12 20:30:34, Gavin Shan wrote: > On Thu, Aug 23, 2012 at 06:21:06PM +0800, Li Haifeng wrote: [...] > >>> From d7cd78f9d71a5c9ddeed02724558096f0bb4508a Mon Sep 17 00:00:00 2001 > >>> From: Haifeng Li <omycle@xxxxxxxxx> > >>> Date: Thu, 23 Aug 2012 16:27:19 +0800 > >>> Subject: [PATCH] Fixup the page of buddy_higher address's calculation > >> > >> Some general questions: > >> Any word about the change? Is it really that obvious? Why do you think the > >> current state is incorrect? How did you find out? > >> > >> And more specific below: > >> > >>> Signed-off-by: Haifeng Li <omycle@xxxxxxxxx> > >>> --- > >>> mm/page_alloc.c | 2 +- > >>> 1 files changed, 1 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c > >>> index ddbc17d..5588f68 100644 > >>> --- a/mm/page_alloc.c > >>> +++ b/mm/page_alloc.c > >>> @@ -579,7 +579,7 @@ static inline void __free_one_page(struct page *page, > >>> combined_idx = buddy_idx & page_idx; > >>> higher_page = page + (combined_idx - page_idx); > >>> buddy_idx = __find_buddy_index(combined_idx, order + 1); > >>> - higher_buddy = page + (buddy_idx - combined_idx); > >>> + higher_buddy = page + (buddy_idx - page_idx); > > Haifeng, Not sure it would be better? At least, the expression > would be more explicitly meaningful than yours. > > higher_buddy = higher_page + (buddy_idx - combined_idx); Yes, indeed. It would be also good to mention that this is a regression since 43506fad (mm/page_alloc.c: simplify calculation of combined index of adjacent buddy lists). IIUC this basically disables the heuristic because page_is_buddy will fail for order+1, right? Maybe 2.6.38+ stable candidate, then. Could you repost with the full changelog, please? Thanks -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>