On Tue, Mar 7, 2017 at 10:40 AM, Tony Luck wrote:
> The commit messages talks about the "only caller" of page_is_buddy().
> But grep shows two call sites:
>
> mm/page_alloc.c:816:if (!page_is_buddy(page, buddy, order))
> mm/page_alloc.c:876:if
On Tue, Mar 7, 2017 at 10:40 AM, Tony Luck wrote:
> The commit messages talks about the "only caller" of page_is_buddy().
> But grep shows two call sites:
>
> mm/page_alloc.c:816:if (!page_is_buddy(page, buddy, order))
> mm/page_alloc.c:876:if (page_is_buddy(higher_page,
On Fri, Dec 16, 2016 at 4:00 AM, Vlastimil Babka wrote:
> On architectures that allow memory holes, page_is_buddy() has to perform
> page_to_pfn() to check for the memory hole. After the previous patch, we have
> the pfn already available in __free_one_page(), which is the only
On Fri, Dec 16, 2016 at 4:00 AM, Vlastimil Babka wrote:
> On architectures that allow memory holes, page_is_buddy() has to perform
> page_to_pfn() to check for the memory hole. After the previous patch, we have
> the pfn already available in __free_one_page(), which is the only caller of
>
On architectures that allow memory holes, page_is_buddy() has to perform
page_to_pfn() to check for the memory hole. After the previous patch, we have
the pfn already available in __free_one_page(), which is the only caller of
page_is_buddy(), so move the check there and avoid page_to_pfn().
On architectures that allow memory holes, page_is_buddy() has to perform
page_to_pfn() to check for the memory hole. After the previous patch, we have
the pfn already available in __free_one_page(), which is the only caller of
page_is_buddy(), so move the check there and avoid page_to_pfn().
6 matches
Mail list logo