Re: [PATCH 10/11] Direct compact when a high-order allocation fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 24, 2010 at 9:09 PM, Mel Gorman <mel@xxxxxxxxx> wrote:
> On Wed, Mar 24, 2010 at 08:59:45PM +0900, Minchan Kim wrote:
>> On Wed, Mar 24, 2010 at 8:11 PM, Mel Gorman <mel@xxxxxxxxx> wrote:
>> > On Wed, Mar 24, 2010 at 08:10:40AM +0900, Minchan Kim wrote:
>> >> Hi, Mel.
>> >>
>> >> On Tue, Mar 23, 2010 at 9:25 PM, Mel Gorman <mel@xxxxxxxxx> wrote:
>> >> > Ordinarily when a high-order allocation fails, direct reclaim is entered to
>> >> > free pages to satisfy the allocation.  With this patch, it is determined if
>> >> > an allocation failed due to external fragmentation instead of low memory
>> >> > and if so, the calling process will compact until a suitable page is
>> >> > freed. Compaction by moving pages in memory is considerably cheaper than
>> >> > paging out to disk and works where there are locked pages or no swap. If
>> >> > compaction fails to free a page of a suitable size, then reclaim will
>> >> > still occur.
>> >> >
>> >> > Direct compaction returns as soon as possible. As each block is compacted,
>> >> > it is checked if a suitable page has been freed and if so, it returns.
>> >> >
>> >> > Signed-off-by: Mel Gorman <mel@xxxxxxxxx>
>> >> > Acked-by: Rik van Riel <riel@xxxxxxxxxx>
Reviewed-by: Minchan Kim <minchan.kim@xxxxxxxxx>

<snip>

>> You're right. I just wanted to change the name as one which imply
>> direct compaction.
>
> I think I'd fully agree with your point if there was more than one way to
> stall a process due to compaction. As it is, direct compaction is the only
> way to meaningfully stall a process and I can't think of alternative stalls
> in the future. Technically, a process using the sysfs or proc triggers for
> compaction also stalls but it's not interesting to count those events.
>
>> That's because I believe we will implement it by backgroud, too.
>
> This is a possibility but in that case it would be a separate process
> like kcompactd and I wouldn't count it as a stall as such.
>
>> Then It's more straightforward, I think. :-)
>>
>> > How about COMPACTSTALL like ALLOCSTALL? :/
>>
>> I wouldn't have a strong objection any more if you insist on it.
>>
>
> I'm not insisting as such, I just don't think renaming it to
> PGSCAN_COMPACT_X would be easier to understand.

Totally, I agree with your opinion.
>From now on, I don't have any objection.




-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]