On Thu, 26 Apr 2012, Andrew Morton wrote:
> > mm->page_table_lock is hotly contested for page fault tests and isn't
> > necessary to do mem_cgroup_uncharge_page() in do_huge_pmd_wp_page().
> >
> > ...
> >
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -968,8 +968,10 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma,
> > spin_lock(&mm->page_table_lock);
> > put_page(page);
> > if (unlikely(!pmd_same(*pmd, orig_pmd))) {
> > + spin_unlock(&mm->page_table_lock);
> > mem_cgroup_uncharge_page(new_page);
> > put_page(new_page);
> > + goto out;
> > } else {
> > pmd_t entry;
> > VM_BUG_ON(!PageHead(page));
>
> But this is on the basically-never-happens race path and will surely have no
> measurable benefit?
>
It happens more often than you may think on page fault tests; how
representative pft has ever been of actual workloads, especially with thp
where the benfits of allocating the hugepage usually result in better
performance in the long-term even for a short-term performance loss, is
debatable. However, all other thp code has always dropped
mm->page_table_lock before calling mem_cgroup_uncharge_page() and this one
seems to have been missed. Worth correcting, in my opinion.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>