* Question About Functions "__free_pages_check" and "check_new_page" in page_alloc.c
@ 2016-05-16 13:42 Wang Xiaoqiang
2016-05-16 15:16 ` Michal Hocko
0 siblings, 1 reply; 5+ messages in thread
From: Wang Xiaoqiang @ 2016-05-16 13:42 UTC (permalink / raw)
To: vbabka, n-horiguchi, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
Hi all,
I am really confused about these two functions. The following code snippet:
if(unlikely(atomic_read(&page->_mapcount) != -1))
bad_reason ="nonzero mapcount";if(unlikely(page->mapping != NULL))
bad_reason ="non-NULL mapping";if(unlikely(page_ref_count(page) !=0))
bad_reason ="nonzero _count";
...
Wouldn't the previous value of "bad_reason" be overwritten by
the later? Hope to receive from you.
--
thx!
Wang Xiaoqiang
[-- Attachment #2: Type: text/html, Size: 1855 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Question About Functions "__free_pages_check" and "check_new_page" in page_alloc.c
2016-05-16 13:42 Question About Functions "__free_pages_check" and "check_new_page" in page_alloc.c Wang Xiaoqiang
@ 2016-05-16 15:16 ` Michal Hocko
2016-05-17 1:06 ` Wang Xiaoqiang
0 siblings, 1 reply; 5+ messages in thread
From: Michal Hocko @ 2016-05-16 15:16 UTC (permalink / raw)
To: Wang Xiaoqiang; +Cc: vbabka, n-horiguchi, linux-kernel, linux-mm
On Mon 16-05-16 21:42:23, Wang Xiaoqiang wrote:
> Hi all,
>
> I am really confused about these two functions. The following code snippet:
>
> if(unlikely(atomic_read(&page->_mapcount) != -1))
> bad_reason ="nonzero mapcount";if(unlikely(page->mapping != NULL))
> bad_reason ="non-NULL mapping";if(unlikely(page_ref_count(page) !=0))
> bad_reason ="nonzero _count";
> ...
> Wouldn't the previous value of "bad_reason" be overwritten by
> the later? Hope to receive from you.
yes it would. Why that would matter. The checks should be in an order
which could give us a more specific reason with later checks. bad_page()
will then print more detailed information.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re:Re: Question About Functions "__free_pages_check" and "check_new_page" in page_alloc.c
2016-05-16 15:16 ` Michal Hocko
@ 2016-05-17 1:06 ` Wang Xiaoqiang
2016-05-17 5:14 ` Vlastimil Babka
0 siblings, 1 reply; 5+ messages in thread
From: Wang Xiaoqiang @ 2016-05-17 1:06 UTC (permalink / raw)
To: Michal Hocko, vbabka, n-horiguchi, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
>yes it would. Why that would matter. The checks should be in an order
>which could give us a more specific reason with later checks. bad_page()
I see, you mean the later "bad_reason" is the superset of the previous one.
>will then print more detailed information.
>--
>Michal Hocko
>SUSE Labs
thank you, Michal.
[-- Attachment #2: Type: text/html, Size: 523 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question About Functions "__free_pages_check" and "check_new_page" in page_alloc.c
2016-05-17 1:06 ` Wang Xiaoqiang
@ 2016-05-17 5:14 ` Vlastimil Babka
2016-05-17 8:17 ` Wang Xiaoqiang
0 siblings, 1 reply; 5+ messages in thread
From: Vlastimil Babka @ 2016-05-17 5:14 UTC (permalink / raw)
To: Wang Xiaoqiang, Michal Hocko, n-horiguchi, linux-kernel, linux-mm
On 05/17/2016 03:06 AM, Wang Xiaoqiang wrote:
>>yes it would. Why that would matter. The checks should be in an order
>>which could give us a more specific reason with later checks. bad_page()
>
> I see, you mean the later "bad_reason" is the superset of the previous one.
Not exactly. It's not possible to sort all the reasons like that. But as
Michal said, bad_page() will print all the relevant info so you can
reconstruct all reasons from it. The bad_reason text is mostly a hint
what to check first.
>>will then print more detailed information.
>>--
>>Michal Hocko
>>SUSE Labs
>
> thank you, Michal.
>
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re:Re: Question About Functions "__free_pages_check" and "check_new_page" in page_alloc.c
2016-05-17 5:14 ` Vlastimil Babka
@ 2016-05-17 8:17 ` Wang Xiaoqiang
0 siblings, 0 replies; 5+ messages in thread
From: Wang Xiaoqiang @ 2016-05-17 8:17 UTC (permalink / raw)
To: Vlastimil Babka; +Cc: Michal Hocko, n-horiguchi, linux-kernel, linux-mm
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
thank you very much! Vlastimil.
At 2016-05-17 13:14:42, "Vlastimil Babka" <vbabka@suse.cz> wrote:
>On 05/17/2016 03:06 AM, Wang Xiaoqiang wrote:
>>>yes it would. Why that would matter. The checks should be in an order
>>>which could give us a more specific reason with later checks. bad_page()
>>
>> I see, you mean the later "bad_reason" is the superset of the previous one.
>
>Not exactly. It's not possible to sort all the reasons like that. But as
>Michal said, bad_page() will print all the relevant info so you can
>reconstruct all reasons from it. The bad_reason text is mostly a hint
>what to check first.
>
>>>will then print more detailed information.
>>>--
>>>Michal Hocko
>>>SUSE Labs
>>
>> thank you, Michal.
[-- Attachment #2: Type: text/html, Size: 1031 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-05-17 8:19 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-16 13:42 Question About Functions "__free_pages_check" and "check_new_page" in page_alloc.c Wang Xiaoqiang
2016-05-16 15:16 ` Michal Hocko
2016-05-17 1:06 ` Wang Xiaoqiang
2016-05-17 5:14 ` Vlastimil Babka
2016-05-17 8:17 ` Wang Xiaoqiang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).