Re:Re: [PATCH] mm/page_alloc: enable alloc bulk when page owner is on

Re:Re: [PATCH] mm/page_alloc: enable alloc bulk when page owner is on

[杨欢]

>> Last alloc bulk version have a bug, when page_owner is on, system maybe
>> crashed due to alloc bulk invoke prep_new_page in irq disabled context,
>> and set_page_owner use page_flag(may GFP_KERNEL) to get memory and save
>> stacktrace.
>> We fix it by a circumvention plan -- bandon alloc bulk feature when
>> page_owner is set.
>> I think both alloc_bulk and page_owner is valuable, so, it's worth to
>> find a way enable alloc bulk when page owner is on.
>
>Why do you think it's valuable?  The point of alloc_bulk is speed.
>Doing the allocation of a stack for each page removes the speed.

>Where's the value?
Without alloc bulk, we also need to alloc pages from loop invoke
alloc_page, and this also will invoke set_page_owner to save stack.
So, find a way to let alloc_bulk work, I think is valuable.
If you don't think so, I sorry for my disturb.

>If you're really interested in making both these things work together,
>then I observed that all of these pages are going to have the same
>allocation stack.  Allocating that stack once per call to alloc_bulk,
>reference counting it and having each page use the shared stack would 

>be a good way of combining the two (it'd even save memory!)
Yes, your idea is very good.

But, how we let set_page_owner knew that recent pages are all in same stack?
Maybe save stack by caller, and passed handle in prep_new_page?
But, I think caller shouldn't care of page trace, it's page owner feature's duties.
Let same stack's page have same magic number maybe a good way, emm
But, even they have same stack, set_page_owner should know how to get memory
rightly (Unless you pass it to, so back to the duties).
In the past, we just pass page gfp to it, in alloc bulk, not right.

>This patch, I think, does not make sense.
Well, this is a simple way that I can find, and not affect perfermance both in normal and
PAGE_OWNER is on, but can work alloc bulk and PAGE_OWNER. 
If you don't think so,  I'm sorry for that

Re:Re: [PATCH] mm/page_alloc: enable alloc bulk when page owner is on

[杨欢]

>> Last alloc bulk version have a bug, when page_owner is on, system maybe
>> crashed due to alloc bulk invoke prep_new_page in irq disabled context,
>> and set_page_owner use page_flag(may GFP_KERNEL) to get memory and save
>> stacktrace.
>> We fix it by a circumvention plan -- bandon alloc bulk feature when
>> page_owner is set.
>> I think both alloc_bulk and page_owner is valuable, so, it's worth to
>> find a way enable alloc bulk when page owner is on.
>
>Why do you think it's valuable?  The point of alloc_bulk is speed.
>Doing the allocation of a stack for each page removes the speed.

>Where's the value?
Without alloc bulk, we also need to alloc pages from loop invoke
alloc_page, and this also will invoke set_page_owner to save stack.
So, find a way to let alloc_bulk work, I think is valuable.
If you don't think so, I sorry for my disturb.

>If you're really interested in making both these things work together,
>then I observed that all of these pages are going to have the same
>allocation stack.  Allocating that stack once per call to alloc_bulk,
>reference counting it and having each page use the shared stack would 

>be a good way of combining the two (it'd even save memory!)
Yes, your idea is very good.

But, how we let set_page_owner knew that recent pages are all in same stack?
Maybe save stack by caller, and passed handle in prep_new_page?
But, I think caller shouldn't care of page trace, it's page owner feature's duties.
Let same stack's page have same magic number maybe a good way, emm
But, even they have same stack, set_page_owner should know how to get memory
rightly (Unless you pass it to, so back to the duties).
In the past, we just pass page gfp to it, in alloc bulk, not right.

>This patch, I think, does not make sense.
Well, this is a simple way that I can find, and not affect perfermance both in normal and
PAGE_OWNER is on, but can work alloc bulk and PAGE_OWNER. 
If you don't think so,  I'm sorry for that

Re: Re: [PATCH] mm/page_alloc: enable alloc bulk when page owner is on

[link]

>



>



>>> Last alloc bulk version have a bug, when page_owner is on, system maybe



>>> crashed due to alloc bulk invoke prep_new_page in irq disabled context,



>>> and set_page_owner use page_flag(may GFP_KERNEL) to get memory and save



>>> stacktrace.



>>> We fix it by a circumvention plan -- bandon alloc bulk feature when



>>> page_owner is set.



>>> I think both alloc_bulk and page_owner is valuable, so, it's worth to



>>> find a way enable alloc bulk when page owner is on.



>>



>>Why do you think it's valuable?  The point of alloc_bulk is speed.

And ok. if you think in debug version use alloc bulk is not valuable.
But I think alloc buk used prep_new_page's way reflect that debug
feature shouldn't assume they can used the same way to get memory,
just like the page it traced.
If we not give debugger some info(alloc_gfp), they have no way, but
to use page's gfp to get memory.(alloc bulk show it's wrong.)

For now, only PAGE_OWNER get memory in prep_new_page, for future,
may have more feature need memory. 
And may have more feature invoke prep_new_page in different context
to the page.

So, give a alloc_gfp to lead debugger to alloc memory is valuable.



>>Doing the allocation of a stack for each page removes the speed.



>



>>Where's the value?



>Without alloc bulk, we also need to alloc pages from loop invoke



>alloc_page, and this also will invoke set_page_owner to save stack.



>So, find a way to let alloc_bulk work, I think is valuable.



>If you don't think so, I sorry for my disturb.



>



>>If you're really interested in making both these things work together,



>>then I observed that all of these pages are going to have the same



>>allocation stack.  Allocating that stack once per call to alloc_bulk,



>>reference counting it and having each page use the shared stack would 



>



>>be a good way of combining the two (it'd even save memory!)



>Yes, your idea is very good.



>



>But, how we let set_page_owner knew that recent pages are all in same stack?



>Maybe save stack by caller, and passed handle in prep_new_page?



>But, I think caller shouldn't care of page trace, it's page owner feature's duties.



>Let same stack's page have same magic number maybe a good way, emm



>But, even they have same stack, set_page_owner should know how to get memory



>rightly (Unless you pass it to, so back to the duties).



>In the past, we just pass page gfp to it, in alloc bulk, not right.



>



>>This patch, I think, does not make sense.



>Well, this is a simple way that I can find, and not affect perfermance both in normal and



>PAGE_OWNER is on, but can work alloc bulk and PAGE_OWNER. 



>If you don't think so,  I'm sorry for that



>



>

Re:Re: [PATCH] mm/page_alloc: enable alloc bulk when page owner is on

[杨欢]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

>> Last alloc bulk version have a bug, when page_owner is on, system maybe
>> crashed due to alloc bulk invoke prep_new_page in irq disabled context,
>> and set_page_owner use page_flag(may GFP_KERNEL) to get memory and save
>> stacktrace.
>> We fix it by a circumvention plan -- bandon alloc bulk feature when
>> page_owner is set.
>> I think both alloc_bulk and page_owner is valuable, so, it's worth to
>> find a way enable alloc bulk when page owner is on.
>
>Why do you think it's valuable?  The point of alloc_bulk is speed.
>Doing the allocation of a stack for each page removes the speed.
>Where's the value?
Without alloc bulk, we also need to alloc pages from loop invoke
alloc_page, and this also will invoke set_page_owner to save stack.
So, find a way to let alloc_bulk work, I think is valuable.
If you don't think so, I sorry for my disturb.
>
>If you're really interested in making both these things work together,
>then I observed that all of these pages are going to have the same
>allocation stack.  Allocating that stack once per call to alloc_bulk,
>reference counting it and having each page use the shared stack would 
>be a good way of combining the two (it'd even save memory!)
Yes, your idea is very good.


But, how we let set_page_owner knew that recent pages are all in same stack?
Maybe save stack by caller, and passed handle in prep_new_page?
But, I think caller shouldn't care of page trace, it's page owner feature's duties.
Let same stack's page have same magic number maybe a good way, emm
But, even they have same stack, set_page_owner should know how to get memory
rightly (Unless you pass it to, so back to the duties).
In the past, we just pass page gfp to it, in alloc bulk, not right.
>
>This patch, I think, does not make sense.
Well, this is a simple way that I can find, and not affect perfermance both in normal and
PAGE_OWNER is on, but can work alloc bulk and PAGE_OWNER. 
If you don't think so,  I'm sorry for that
>





[-- Attachment #2: Type: text/html, Size: 2345 bytes --]