lkml.org 
[lkml]   [2013]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH resend] rmap: recompute pgoff for unmapping huge page
On Mon, 4 Mar 2013 20:47:31 +0800 Hillf Danton <dhillf@gmail.com> wrote:

> [Resend due to error in delivering to linux-kernel@vger.kernel.org,
> caused probably by the rich format provided by the mail agent by default.]
>
> We have to recompute pgoff if the given page is huge, since result based on
> HPAGE_SIZE is not approapriate for scanning the vma interval tree, as shown
> by commit 36e4f20af833(hugetlb: do not use vma_hugecache_offset() for
> vma_prio_tree_foreach)
>
> ...
>
> @@ -1513,6 +1513,9 @@ static int try_to_unmap_file(struct page
> unsigned long max_nl_size = 0;
> unsigned int mapcount;
>
> + if (PageHuge(page))
> + pgoff = page->index << compound_order(page);
> +
> mutex_lock(&mapping->i_mmap_mutex);
> vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff, pgoff) {
> unsigned long address = vma_address(page, vma);

Also, what does this patch actually do?

I have a canned response nowadays:

When writing a changelog, please describe the end-user-visible effects
of that bug, so that others can more easily decide which kernel
version(s) should be fixed, and so that downstream kernel maintainers
can more easily work out whether this patch will fix a problem which
they or their customers are observing.



\
 
 \ /
  Last update: 2013-03-07 00:21    [W:0.040 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site