On Mon 23-05-16 23:31:09, yoma sophian wrote:
> hi Michal
>
> 2016-05-23 22:47 GMT+08:00, Michal Hocko <mhocko@xxxxxxxxxx>:
> > On Mon 23-05-16 14:47:51, yoma sophian wrote:
> >> hi all:
> >> I got something wired that
> >> 1. in softirq, there is a page order 0 allocation request
> >> 2. Normal/High zone are free enough for order 0 page.
> >> 3. but somehow kernel return order 0 allocation fail.
> >>
> >> My kernel version is 3.10 and below is kernel log:
> >> from memory info,
> >
> > Can you reproduce it with the current vanlilla tree?
>
> I think it would be quite hard, since this allocation failuer comes
> when a lot of program, such as Youtube, opera, etc. running on ARM
> processor at the same time.
> Or is there any patch in vanlilla tree I can used for checking?
No, but 3.10 is quite old and it is preferable to reproduce your issue
on the clean and up-to-date vanilla kernel to get a better chances to
get your problem resolved.
> > [...]
> >> [ 94.586588] ksoftirqd/0: page allocation failure: order:0, mode:0x20
> > [...]
> >> [ 94.865776] Normal free:63768kB min:2000kB low:2500kB high:3000kB
> > [...]
> >> [ 8606.701343] CompositorTileW: page allocation failure: order:0,
> >> mode:0x20
> > [...]
> >> [ 8606.703590] Normal free:60684kB min:2000kB low:2500kB high:3000kB
> >
> > This is a lot of free memory to block GFP_ATOMIC. One possible
> > explanation would be that this is a race with somebody releasing a lot
> I will try to add memory free at buffered_rmqueue like below xxx place
> buffered_rmqueue -->
> if (likely(order == 0)) {
> ..................
> if (list_empty(list)) {
> pcp->count += rmqueue_bulk(zone, 0,
> pcp->batch, list,
> migratetype, cold);
> if (unlikely(list_empty(list)))
> goto failed; xxxxx ==> to show
> memory free info
I would just mark NR_FREE_PAGES before and after allocation request.
Something like:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8f3bfc435ee..a1337aa7e897 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3565,6 +3565,9 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
enum compact_result compact_result;
int compaction_retries = 0;
int no_progress_loops = 0;
+ unsigned long nr_free_before;
+
+ nr_free_before = global_page_state(NR_FREE_PAGES);
/*
* In the slowpath, we sanity check order to avoid ever trying to
@@ -3624,6 +3627,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
* to fail.
*/
WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL);
+ pr_info("nr_free_before:%lu nr_free_now:%lu\n", nr_free_before, global_page_state(NR_FREE_PAGES));
goto nopage;
}
You can then compare the numbers before after and the allocation failure
to see whether there is a large gap.
--
Michal Hocko
SUSE Labs
--
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>