On 01/19/2017 12:51 PM, Michal Hocko wrote:
> On Fri 13-01-17 16:14:29, Joonsoo Kim wrote:
>> From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
>>
>> It's inefficient to retrieve buddy information for fragmentation index
>> calculation on every order. By using some stack memory, we could retrieve
>> it once and reuse it to compute all the required values. MAX_ORDER is
>> usually small enough so there is no big risk about stack overflow.
>>
>> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
>> ---
>> mm/vmstat.c | 25 ++++++++++++-------------
>> 1 file changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/mm/vmstat.c b/mm/vmstat.c
>> index 7c28df3..e1ca5eb 100644
>> --- a/mm/vmstat.c
>> +++ b/mm/vmstat.c
>> @@ -821,7 +821,7 @@ unsigned long node_page_state(struct pglist_data *pgdat,
>> struct contig_page_info {
>> unsigned long free_pages;
>> unsigned long free_blocks_total;
>> - unsigned long free_blocks_suitable;
>> + unsigned long free_blocks_order[MAX_ORDER];
>> };
>
> I haven't looked at the rest of the patch becaust this has already
> raised a red flag. This will increase the size of the structure quite a
> bit and from a quick look at least compaction_suitable->fragmentation_index
> will call with this allocated on the stack and this can be pretty deep
> on the call chain already.
Yeah, but compaction_suitable() is usually called at a point where
you're deciding whether to do more reclaim or compaction in the same
context, and both of those most likely have much larger stacks than this.
--
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/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>