From: Michal Hocko <mhocko@kernel.org> To: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Hugh Dickins <hughd@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mgorman@suse.de>, David Rientjes <rientjes@google.com>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, Hillf Danton <hillf.zj@alibaba-inc.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Subject: Re: [PATCH 0/3] OOM detection rework v4 Date: Wed, 2 Mar 2016 10:50:56 +0100 [thread overview] Message-ID: <20160302095056.GB26701@dhcp22.suse.cz> (raw) In-Reply-To: <20160302021954.GA22355@js1304-P5Q-DELUXE> On Wed 02-03-16 11:19:54, Joonsoo Kim wrote: > On Mon, Feb 29, 2016 at 10:02:13PM +0100, Michal Hocko wrote: [...] > > > + /* > > > + * OK, so the watermak check has failed. Make sure we do all the > > > + * retries for !costly high order requests and hope that multiple > > > + * runs of compaction will generate some high order ones for us. > > > + * > > > + * XXX: ideally we should teach the compaction to try _really_ hard > > > + * if we are in the retry path - something like priority 0 for the > > > + * reclaim > > > + */ > > > + if (order && order <= PAGE_ALLOC_COSTLY_ORDER) > > > + return true; > > > + > > > return false; > > This seems not a proper fix. Checking watermark with high order has > another meaning that there is high order page or not. This isn't > what we want here. Why not? Why should we retry the reclaim if we do not have >=order page available? Reclaim itself doesn't guarantee any of the freed pages will form the requested order. The ordering on the LRU lists is pretty much random wrt. pfn ordering. On the other hand if we have a page available which is just hidden by watermarks then it makes perfect sense to retry and free even order-0 pages. > So, following fix is needed. > 'if (order)' check isn't needed. It is used to clarify the meaning of > this fix. You can remove it. > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 1993894..8c80375 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3125,6 +3125,10 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order, > if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) > return false; > > + /* To check whether compaction is available or not */ > + if (order) > + order = 0; > + This would enforce the order 0 wmark check which is IMHO not correct as per above. > /* > * Keep reclaiming pages while there is a chance this will lead > * somewhere. If none of the target zones can satisfy our allocation > > > > } > > > > > > @@ -3281,11 +3293,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > > > goto noretry; > > > > > > /* > > > - * Costly allocations might have made a progress but this doesn't mean > > > - * their order will become available due to high fragmentation so do > > > - * not reset the no progress counter for them > > > + * High order allocations might have made a progress but this doesn't > > > + * mean their order will become available due to high fragmentation so > > > + * do not reset the no progress counter for them > > > */ > > > - if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER) > > > + if (did_some_progress && !order) > > > no_progress_loops = 0; > > > else > > > no_progress_loops++; > > This unconditionally increases no_progress_loops for high order > allocation, so, after 16 iterations, it will fail. If compaction isn't > enabled in Kconfig, 16 times reclaim attempt would not be sufficient > to make high order page. Should we consider this case also? How many retries would help? I do not think any number will work reliably. Configurations without compaction enabled are asking for problems by definition IMHO. Relying on order-0 reclaim for high order allocations simply cannot work. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Hugh Dickins <hughd@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mgorman@suse.de>, David Rientjes <rientjes@google.com>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, Hillf Danton <hillf.zj@alibaba-inc.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Subject: Re: [PATCH 0/3] OOM detection rework v4 Date: Wed, 2 Mar 2016 10:50:56 +0100 [thread overview] Message-ID: <20160302095056.GB26701@dhcp22.suse.cz> (raw) In-Reply-To: <20160302021954.GA22355@js1304-P5Q-DELUXE> On Wed 02-03-16 11:19:54, Joonsoo Kim wrote: > On Mon, Feb 29, 2016 at 10:02:13PM +0100, Michal Hocko wrote: [...] > > > + /* > > > + * OK, so the watermak check has failed. Make sure we do all the > > > + * retries for !costly high order requests and hope that multiple > > > + * runs of compaction will generate some high order ones for us. > > > + * > > > + * XXX: ideally we should teach the compaction to try _really_ hard > > > + * if we are in the retry path - something like priority 0 for the > > > + * reclaim > > > + */ > > > + if (order && order <= PAGE_ALLOC_COSTLY_ORDER) > > > + return true; > > > + > > > return false; > > This seems not a proper fix. Checking watermark with high order has > another meaning that there is high order page or not. This isn't > what we want here. Why not? Why should we retry the reclaim if we do not have >=order page available? Reclaim itself doesn't guarantee any of the freed pages will form the requested order. The ordering on the LRU lists is pretty much random wrt. pfn ordering. On the other hand if we have a page available which is just hidden by watermarks then it makes perfect sense to retry and free even order-0 pages. > So, following fix is needed. > 'if (order)' check isn't needed. It is used to clarify the meaning of > this fix. You can remove it. > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 1993894..8c80375 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3125,6 +3125,10 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order, > if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) > return false; > > + /* To check whether compaction is available or not */ > + if (order) > + order = 0; > + This would enforce the order 0 wmark check which is IMHO not correct as per above. > /* > * Keep reclaiming pages while there is a chance this will lead > * somewhere. If none of the target zones can satisfy our allocation > > > > } > > > > > > @@ -3281,11 +3293,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > > > goto noretry; > > > > > > /* > > > - * Costly allocations might have made a progress but this doesn't mean > > > - * their order will become available due to high fragmentation so do > > > - * not reset the no progress counter for them > > > + * High order allocations might have made a progress but this doesn't > > > + * mean their order will become available due to high fragmentation so > > > + * do not reset the no progress counter for them > > > */ > > > - if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER) > > > + if (did_some_progress && !order) > > > no_progress_loops = 0; > > > else > > > no_progress_loops++; > > This unconditionally increases no_progress_loops for high order > allocation, so, after 16 iterations, it will fail. If compaction isn't > enabled in Kconfig, 16 times reclaim attempt would not be sufficient > to make high order page. Should we consider this case also? How many retries would help? I do not think any number will work reliably. Configurations without compaction enabled are asking for problems by definition IMHO. Relying on order-0 reclaim for high order allocations simply cannot work. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-03-02 9:51 UTC|newest] Thread overview: 299+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-15 18:19 [PATCH 0/3] OOM detection rework v4 Michal Hocko 2015-12-15 18:19 ` Michal Hocko 2015-12-15 18:19 ` [PATCH 1/3] mm, oom: rework oom detection Michal Hocko 2015-12-15 18:19 ` Michal Hocko 2016-01-14 22:58 ` David Rientjes 2016-01-14 22:58 ` David Rientjes 2016-01-16 1:07 ` Tetsuo Handa 2016-01-16 1:07 ` Tetsuo Handa 2016-01-19 22:48 ` David Rientjes 2016-01-19 22:48 ` David Rientjes 2016-01-20 11:13 ` Tetsuo Handa 2016-01-20 11:13 ` Tetsuo Handa 2016-01-20 13:13 ` Michal Hocko 2016-01-20 13:13 ` Michal Hocko 2016-04-04 8:23 ` Vladimir Davydov 2016-04-04 8:23 ` Vladimir Davydov 2016-04-04 9:42 ` Michal Hocko 2016-04-04 9:42 ` Michal Hocko 2015-12-15 18:19 ` [PATCH 2/3] mm: throttle on IO only when there are too many dirty and writeback pages Michal Hocko 2015-12-15 18:19 ` Michal Hocko 2016-03-17 11:35 ` Tetsuo Handa 2016-03-17 11:35 ` Tetsuo Handa 2016-03-17 12:01 ` Michal Hocko 2016-03-17 12:01 ` Michal Hocko 2015-12-15 18:19 ` [PATCH 3/3] mm: use watermak checks for __GFP_REPEAT high order allocations Michal Hocko 2015-12-15 18:19 ` Michal Hocko 2015-12-16 23:35 ` [PATCH 0/3] OOM detection rework v4 Andrew Morton 2015-12-16 23:35 ` Andrew Morton 2015-12-18 12:12 ` Michal Hocko 2015-12-18 12:12 ` Michal Hocko 2015-12-16 23:58 ` Andrew Morton 2015-12-16 23:58 ` Andrew Morton 2015-12-18 13:15 ` Michal Hocko 2015-12-18 13:15 ` Michal Hocko 2015-12-18 16:35 ` Johannes Weiner 2015-12-18 16:35 ` Johannes Weiner 2015-12-24 12:41 ` Tetsuo Handa 2015-12-24 12:41 ` Tetsuo Handa 2015-12-28 12:08 ` Tetsuo Handa 2015-12-28 12:08 ` Tetsuo Handa 2015-12-28 14:13 ` Tetsuo Handa 2015-12-28 14:13 ` Tetsuo Handa 2016-01-06 12:44 ` Vlastimil Babka 2016-01-06 12:44 ` Vlastimil Babka 2016-01-08 12:37 ` Michal Hocko 2016-01-08 12:37 ` Michal Hocko 2015-12-29 16:32 ` Michal Hocko 2015-12-29 16:32 ` Michal Hocko 2015-12-30 15:05 ` Tetsuo Handa 2015-12-30 15:05 ` Tetsuo Handa 2016-01-02 15:47 ` Tetsuo Handa 2016-01-02 15:47 ` Tetsuo Handa 2016-01-20 12:24 ` Michal Hocko 2016-01-20 12:24 ` Michal Hocko 2016-01-27 23:18 ` David Rientjes 2016-01-27 23:18 ` David Rientjes 2016-01-28 21:19 ` Michal Hocko 2016-01-28 21:19 ` Michal Hocko 2015-12-29 16:27 ` Michal Hocko 2015-12-29 16:27 ` Michal Hocko 2016-01-28 20:40 ` [PATCH 4/3] mm, oom: drop the last allocation attempt before out_of_memory Michal Hocko 2016-01-28 20:40 ` Michal Hocko 2016-01-28 21:36 ` Johannes Weiner 2016-01-28 21:36 ` Johannes Weiner 2016-01-28 23:19 ` David Rientjes 2016-01-28 23:19 ` David Rientjes 2016-01-28 23:51 ` Johannes Weiner 2016-01-28 23:51 ` Johannes Weiner 2016-01-29 10:39 ` Tetsuo Handa 2016-01-29 10:39 ` Tetsuo Handa 2016-01-29 15:32 ` Michal Hocko 2016-01-29 15:32 ` Michal Hocko 2016-01-30 12:18 ` Tetsuo Handa 2016-01-30 12:18 ` Tetsuo Handa 2016-01-29 15:23 ` Michal Hocko 2016-01-29 15:23 ` Michal Hocko 2016-01-29 15:24 ` Michal Hocko 2016-01-29 15:24 ` Michal Hocko 2016-01-28 21:19 ` [PATCH 5/3] mm, vmscan: make zone_reclaimable_pages more precise Michal Hocko 2016-01-28 21:19 ` Michal Hocko 2016-01-28 23:20 ` David Rientjes 2016-01-28 23:20 ` David Rientjes 2016-01-29 3:41 ` Hillf Danton 2016-01-29 3:41 ` Hillf Danton 2016-01-29 10:35 ` Tetsuo Handa 2016-01-29 10:35 ` Tetsuo Handa 2016-01-29 15:17 ` Michal Hocko 2016-01-29 15:17 ` Michal Hocko 2016-01-29 21:30 ` Tetsuo Handa 2016-01-29 21:30 ` Tetsuo Handa 2016-02-03 13:27 ` [PATCH 0/3] OOM detection rework v4 Michal Hocko 2016-02-03 13:27 ` Michal Hocko 2016-02-03 22:58 ` David Rientjes 2016-02-03 22:58 ` David Rientjes 2016-02-04 12:57 ` Michal Hocko 2016-02-04 12:57 ` Michal Hocko 2016-02-04 13:10 ` Tetsuo Handa 2016-02-04 13:10 ` Tetsuo Handa 2016-02-04 13:39 ` Michal Hocko 2016-02-04 13:39 ` Michal Hocko 2016-02-04 14:24 ` Michal Hocko 2016-02-04 14:24 ` Michal Hocko 2016-02-07 4:09 ` Tetsuo Handa 2016-02-07 4:09 ` Tetsuo Handa 2016-02-15 20:06 ` Michal Hocko 2016-02-15 20:06 ` Michal Hocko 2016-02-16 13:10 ` Tetsuo Handa 2016-02-16 13:10 ` Tetsuo Handa 2016-02-16 15:19 ` Michal Hocko 2016-02-16 15:19 ` Michal Hocko 2016-02-25 3:47 ` Hugh Dickins 2016-02-25 3:47 ` Hugh Dickins 2016-02-25 6:48 ` Sergey Senozhatsky 2016-02-25 6:48 ` Sergey Senozhatsky 2016-02-25 9:17 ` Hillf Danton 2016-02-25 9:17 ` Hillf Danton 2016-02-25 9:27 ` Michal Hocko 2016-02-25 9:27 ` Michal Hocko 2016-02-25 9:48 ` Hillf Danton 2016-02-25 9:48 ` Hillf Danton 2016-02-25 11:02 ` Sergey Senozhatsky 2016-02-25 11:02 ` Sergey Senozhatsky 2016-02-25 9:23 ` Michal Hocko 2016-02-25 9:23 ` Michal Hocko 2016-02-26 6:32 ` Hugh Dickins 2016-02-26 6:32 ` Hugh Dickins 2016-02-26 7:54 ` Hillf Danton 2016-02-26 7:54 ` Hillf Danton 2016-02-26 9:24 ` Michal Hocko 2016-02-26 9:24 ` Michal Hocko 2016-02-26 10:27 ` Hillf Danton 2016-02-26 10:27 ` Hillf Danton 2016-02-26 13:49 ` Michal Hocko 2016-02-26 13:49 ` Michal Hocko 2016-02-26 9:33 ` Michal Hocko 2016-02-26 9:33 ` Michal Hocko 2016-02-29 21:02 ` Michal Hocko 2016-02-29 21:02 ` Michal Hocko 2016-03-02 2:19 ` Joonsoo Kim 2016-03-02 2:19 ` Joonsoo Kim 2016-03-02 9:50 ` Michal Hocko [this message] 2016-03-02 9:50 ` Michal Hocko 2016-03-02 13:32 ` Joonsoo Kim 2016-03-02 13:32 ` Joonsoo Kim 2016-03-02 14:06 ` Michal Hocko 2016-03-02 14:06 ` Michal Hocko 2016-03-02 14:34 ` Joonsoo Kim 2016-03-02 14:34 ` Joonsoo Kim 2016-03-03 9:26 ` Michal Hocko 2016-03-03 9:26 ` Michal Hocko 2016-03-03 10:29 ` Tetsuo Handa 2016-03-03 10:29 ` Tetsuo Handa 2016-03-03 14:10 ` Joonsoo Kim 2016-03-03 14:10 ` Joonsoo Kim 2016-03-03 15:25 ` Michal Hocko 2016-03-03 15:25 ` Michal Hocko 2016-03-04 5:23 ` Joonsoo Kim 2016-03-04 5:23 ` Joonsoo Kim 2016-03-04 15:15 ` Michal Hocko 2016-03-04 15:15 ` Michal Hocko 2016-03-04 17:39 ` Michal Hocko 2016-03-04 17:39 ` Michal Hocko 2016-03-07 5:23 ` Joonsoo Kim 2016-03-07 5:23 ` Joonsoo Kim 2016-03-03 15:50 ` Vlastimil Babka 2016-03-03 15:50 ` Vlastimil Babka 2016-03-03 16:26 ` Michal Hocko 2016-03-03 16:26 ` Michal Hocko 2016-03-04 7:10 ` Joonsoo Kim 2016-03-04 7:10 ` Joonsoo Kim 2016-03-02 15:01 ` Minchan Kim 2016-03-02 15:01 ` Minchan Kim 2016-03-07 16:08 ` [PATCH] mm, oom: protect !costly allocations some more (was: Re: [PATCH 0/3] OOM detection rework v4) Michal Hocko 2016-03-07 16:08 ` Michal Hocko 2016-03-08 3:51 ` Sergey Senozhatsky 2016-03-08 3:51 ` Sergey Senozhatsky 2016-03-08 9:08 ` Michal Hocko 2016-03-08 9:08 ` Michal Hocko 2016-03-08 9:24 ` Sergey Senozhatsky 2016-03-08 9:24 ` Sergey Senozhatsky 2016-03-08 9:24 ` [PATCH] mm, oom: protect !costly allocations some more Vlastimil Babka 2016-03-08 9:24 ` Vlastimil Babka 2016-03-08 9:32 ` Sergey Senozhatsky 2016-03-08 9:32 ` Sergey Senozhatsky 2016-03-08 9:46 ` Michal Hocko 2016-03-08 9:46 ` Michal Hocko 2016-03-08 9:52 ` Vlastimil Babka 2016-03-08 9:52 ` Vlastimil Babka 2016-03-08 10:10 ` Michal Hocko 2016-03-08 10:10 ` Michal Hocko 2016-03-08 11:12 ` Vlastimil Babka 2016-03-08 11:12 ` Vlastimil Babka 2016-03-08 12:22 ` Michal Hocko 2016-03-08 12:22 ` Michal Hocko 2016-03-08 12:29 ` Vlastimil Babka 2016-03-08 12:29 ` Vlastimil Babka 2016-03-08 9:58 ` [PATCH] mm, oom: protect !costly allocations some more (was: Re: [PATCH 0/3] OOM detection rework v4) Sergey Senozhatsky 2016-03-08 9:58 ` Sergey Senozhatsky 2016-03-08 13:57 ` Michal Hocko 2016-03-08 13:57 ` Michal Hocko 2016-03-08 10:36 ` Hugh Dickins 2016-03-08 13:42 ` [PATCH 0/2] oom rework: high order enahncements Michal Hocko 2016-03-08 13:42 ` Michal Hocko 2016-03-08 13:42 ` [PATCH 1/3] mm, compaction: change COMPACT_ constants into enum Michal Hocko 2016-03-08 13:42 ` Michal Hocko 2016-03-08 14:19 ` Vlastimil Babka 2016-03-08 14:19 ` Vlastimil Babka 2016-03-09 3:55 ` Hillf Danton 2016-03-09 3:55 ` Hillf Danton 2016-03-08 13:42 ` [PATCH 2/3] mm, compaction: cover all compaction mode in compact_zone Michal Hocko 2016-03-08 13:42 ` Michal Hocko 2016-03-08 14:22 ` Vlastimil Babka 2016-03-08 14:22 ` Vlastimil Babka 2016-03-09 3:57 ` Hillf Danton 2016-03-09 3:57 ` Hillf Danton 2016-03-08 13:42 ` [PATCH 3/3] mm, oom: protect !costly allocations some more Michal Hocko 2016-03-08 13:42 ` Michal Hocko 2016-03-08 14:34 ` Vlastimil Babka 2016-03-08 14:34 ` Vlastimil Babka 2016-03-08 14:48 ` Michal Hocko 2016-03-08 14:48 ` Michal Hocko 2016-03-08 15:03 ` Vlastimil Babka 2016-03-08 15:03 ` Vlastimil Babka 2016-03-09 11:11 ` Michal Hocko 2016-03-09 11:11 ` Michal Hocko 2016-03-09 14:07 ` Vlastimil Babka 2016-03-09 14:07 ` Vlastimil Babka 2016-03-11 12:17 ` Hugh Dickins 2016-03-11 12:17 ` Hugh Dickins 2016-03-11 13:06 ` Michal Hocko 2016-03-11 13:06 ` Michal Hocko 2016-03-11 19:08 ` Hugh Dickins 2016-03-11 19:08 ` Hugh Dickins 2016-03-14 16:21 ` Michal Hocko 2016-03-14 16:21 ` Michal Hocko 2016-03-08 15:19 ` [PATCH] mm, oom: protect !costly allocations some more (was: Re: [PATCH 0/3] OOM detection rework v4) Joonsoo Kim 2016-03-08 15:19 ` Joonsoo Kim 2016-03-08 16:05 ` Michal Hocko 2016-03-08 16:05 ` Michal Hocko 2016-03-08 17:03 ` Joonsoo Kim 2016-03-08 17:03 ` Joonsoo Kim 2016-03-09 10:41 ` Michal Hocko 2016-03-09 10:41 ` Michal Hocko 2016-03-11 14:53 ` Joonsoo Kim 2016-03-11 14:53 ` Joonsoo Kim 2016-03-11 15:20 ` Michal Hocko 2016-03-11 15:20 ` Michal Hocko 2016-02-29 20:35 ` [PATCH 0/3] OOM detection rework v4 Michal Hocko 2016-03-01 7:29 ` Hugh Dickins 2016-03-01 7:29 ` Hugh Dickins 2016-03-01 13:38 ` Michal Hocko 2016-03-01 13:38 ` Michal Hocko 2016-03-01 14:40 ` Michal Hocko 2016-03-01 14:40 ` Michal Hocko 2016-03-01 18:14 ` Vlastimil Babka 2016-03-01 18:14 ` Vlastimil Babka 2016-03-02 2:55 ` Joonsoo Kim 2016-03-02 2:55 ` Joonsoo Kim 2016-03-02 12:37 ` Michal Hocko 2016-03-02 12:37 ` Michal Hocko 2016-03-02 14:06 ` Joonsoo Kim 2016-03-02 14:06 ` Joonsoo Kim 2016-03-02 12:24 ` Michal Hocko 2016-03-02 13:00 ` Michal Hocko 2016-03-02 13:22 ` Vlastimil Babka 2016-03-02 13:22 ` Vlastimil Babka 2016-03-02 2:28 ` Joonsoo Kim 2016-03-02 2:28 ` Joonsoo Kim 2016-03-02 12:39 ` Michal Hocko 2016-03-02 12:39 ` Michal Hocko 2016-03-03 9:54 ` Hugh Dickins 2016-03-03 12:32 ` Michal Hocko 2016-03-03 12:32 ` Michal Hocko 2016-03-03 20:57 ` Hugh Dickins 2016-03-03 20:57 ` Hugh Dickins 2016-03-04 7:41 ` Vlastimil Babka 2016-03-04 7:41 ` Vlastimil Babka 2016-03-04 7:53 ` Joonsoo Kim 2016-03-04 7:53 ` Joonsoo Kim 2016-03-04 12:28 ` Michal Hocko 2016-03-04 12:28 ` Michal Hocko 2016-03-11 10:45 ` Tetsuo Handa 2016-03-11 10:45 ` Tetsuo Handa 2016-03-11 13:08 ` Michal Hocko 2016-03-11 13:08 ` Michal Hocko 2016-03-11 13:32 ` Tetsuo Handa 2016-03-11 13:32 ` Tetsuo Handa 2016-03-11 15:28 ` Michal Hocko 2016-03-11 15:28 ` Michal Hocko 2016-03-11 16:49 ` Tetsuo Handa 2016-03-11 16:49 ` Tetsuo Handa 2016-03-11 17:00 ` Michal Hocko 2016-03-11 17:00 ` Michal Hocko 2016-03-11 17:20 ` Tetsuo Handa 2016-03-11 17:20 ` Tetsuo Handa 2016-03-12 4:08 ` Tetsuo Handa 2016-03-12 4:08 ` Tetsuo Handa 2016-03-13 14:41 ` Tetsuo Handa 2016-03-13 14:41 ` Tetsuo Handa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160302095056.GB26701@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=hillf.zj@alibaba-inc.com \ --cc=hughd@google.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=rientjes@google.com \ --cc=sergey.senozhatsky.work@gmail.com \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.