Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-12 Thread Vlastimil Babka
On 05/03/2016 07:23 AM, js1...@gmail.com wrote: From: Joonsoo Kim Currently, we store each page's allocation stacktrace on corresponding page_ext structure and it requires a lot of memory. This causes the problem that memory tight system doesn't work well if page_owner is enabled. Moreover, eve

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-10 Thread Michal Hocko
On Tue 10-05-16 16:07:14, Joonsoo Kim wrote: > 2016-05-05 4:40 GMT+09:00 Michal Hocko : > > On Thu 05-05-16 00:30:35, Joonsoo Kim wrote: > >> 2016-05-04 18:21 GMT+09:00 Michal Hocko : > > [...] > >> > Do we really consume 512B of stack during reclaim. That sounds more than > >> > worrying to me. >

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-10 Thread Joonsoo Kim
2016-05-05 4:40 GMT+09:00 Michal Hocko : > On Thu 05-05-16 00:30:35, Joonsoo Kim wrote: >> 2016-05-04 18:21 GMT+09:00 Michal Hocko : > [...] >> > Do we really consume 512B of stack during reclaim. That sounds more than >> > worrying to me. >> >> Hmm...I checked it by ./script/stackusage and result

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-04 Thread Michal Hocko
On Thu 05-05-16 00:45:45, Joonsoo Kim wrote: > 2016-05-05 0:30 GMT+09:00 Joonsoo Kim : > > 2016-05-04 18:21 GMT+09:00 Michal Hocko : > >> On Wed 04-05-16 11:14:50, Joonsoo Kim wrote: > >>> On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: > >>> > On Tue 03-05-16 14:23:04, Joonsoo Kim wr

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-04 Thread Michal Hocko
On Thu 05-05-16 00:30:35, Joonsoo Kim wrote: > 2016-05-04 18:21 GMT+09:00 Michal Hocko : [...] > > Do we really consume 512B of stack during reclaim. That sounds more than > > worrying to me. > > Hmm...I checked it by ./script/stackusage and result is as below. > > shrink_zone() 128 > shrink_zone

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-04 Thread Joonsoo Kim
2016-05-05 0:30 GMT+09:00 Joonsoo Kim : > 2016-05-04 18:21 GMT+09:00 Michal Hocko : >> On Wed 04-05-16 11:14:50, Joonsoo Kim wrote: >>> On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: >>> > On Tue 03-05-16 14:23:04, Joonsoo Kim wrote: >> [...] >>> > > Memory saving looks as following.

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-04 Thread Joonsoo Kim
2016-05-04 18:23 GMT+09:00 Michal Hocko : > On Wed 04-05-16 11:35:00, Joonsoo Kim wrote: > [...] >> Oops... I think more deeply and change my mind. In recursion case, >> stack is consumed more than 1KB and it would be a problem. I think >> that best approach is using preallocated per cpu entry. It

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-04 Thread Joonsoo Kim
2016-05-04 18:21 GMT+09:00 Michal Hocko : > On Wed 04-05-16 11:14:50, Joonsoo Kim wrote: >> On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: >> > On Tue 03-05-16 14:23:04, Joonsoo Kim wrote: > [...] >> > > Memory saving looks as following. (Boot 4GB memory system with >> > > page_owne

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-04 Thread Michal Hocko
On Wed 04-05-16 11:35:00, Joonsoo Kim wrote: [...] > Oops... I think more deeply and change my mind. In recursion case, > stack is consumed more than 1KB and it would be a problem. I think > that best approach is using preallocated per cpu entry. It will also > close recursion detection issue by pa

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-04 Thread Michal Hocko
On Wed 04-05-16 11:14:50, Joonsoo Kim wrote: > On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: > > On Tue 03-05-16 14:23:04, Joonsoo Kim wrote: [...] > > > Memory saving looks as following. (Boot 4GB memory system with page_owner) > > > > > > 92274688 bytes -> 25165824 bytes > > > >

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-03 Thread Joonsoo Kim
On Wed, May 04, 2016 at 11:14:50AM +0900, Joonsoo Kim wrote: > On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: > > On Tue 03-05-16 14:23:04, Joonsoo Kim wrote: > > > From: Joonsoo Kim > > > > > > Currently, we store each page's allocation stacktrace on corresponding > > > page_ext s

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-03 Thread Joonsoo Kim
On Tue, May 03, 2016 at 10:53:56AM +0200, Michal Hocko wrote: > On Tue 03-05-16 14:23:04, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > Currently, we store each page's allocation stacktrace on corresponding > > page_ext structure and it requires a lot of memory. This causes the problem > > tha

Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-03 Thread Michal Hocko
On Tue 03-05-16 14:23:04, Joonsoo Kim wrote: > From: Joonsoo Kim > > Currently, we store each page's allocation stacktrace on corresponding > page_ext structure and it requires a lot of memory. This causes the problem > that memory tight system doesn't work well if page_owner is enabled. > Moreov

[PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace

2016-05-02 Thread js1304
From: Joonsoo Kim Currently, we store each page's allocation stacktrace on corresponding page_ext structure and it requires a lot of memory. This causes the problem that memory tight system doesn't work well if page_owner is enabled. Moreover, even with this large memory consumption, we cannot ge