Re: compaction: why depends on HUGETLB_PAGE

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

 



> > Please could you elaborate a little more why depending on
> > compaction to satisfy other high-order allocation is not good.
> >
> 
> At the very least, it's not a situation that has been tested heavily and
> because other high-order allocations are typically not movable. In the
> worst case, if they are both frequent and long-lived they *may* eventually
> encounter fragmentation-related problems. This uncertainity is why it's
> not good. It gets worse if there is no swap as eventually all movable pages
> will be compacted as much as possible but there still might not be enough
> contiguous memory for a high-order page because other pages are pinned.

I am interested in this topic too.

How about using compaction for infrequent short-lived
high-order allocations? Is there any problem in that case?
(apart from the point that it is not tested for that purpose)

Also how about using compaction as a preparation
for partial refresh?

RR

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

--
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]