Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1397749

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

Show all headers | View raw

2016-05-05 4:40 GMT+09:00 Michal Hocko <mhocko@kernel.org>:
> On Thu 05-05-16 00:30:35, Joonsoo Kim wrote:
>> 2016-05-04 18:21 GMT+09:00 Michal Hocko <mhocko@kernel.org>:
> [...]
>> > 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_memcg() 248
>> shrink_active_list() 176
>>
>> We have a call path that shrink_zone() -> shrink_zone_memcg() ->
>> shrink_active_list().
>> I'm not sure whether it is the deepest path or not.
>
> This is definitely not the deepest path. Slab shrinkers can take more
> but 512B is still a lot. Some call paths are already too deep when
> calling into the allocator and some of them already use GFP_NOFS to
> prevent from potentially deep callchain slab shrinkers. Anyway worth
> exploring for better solutions.
>
> And I believe it would be better to solve this in the stackdepot
> directly so other users do not have to invent their own ways around the
> same issue. I have just checked the code and set_track uses save_stack
> which does the same thing and it seems to be called from the slab
> allocator. I have missed this usage before so the problem already does
> exist. It would be unfair to request you to fix that in order to add a
> new user. It would be great if this got addressed though.

Yes, fixing it in stackdepot looks more reasonable.
Then, I will just change PAGE_OWNER_STACK_DEPTH from 64 to 16 and
leave the code as is for now. With this change, we will just consume 128B stack
and would not cause stack problem. If anyone has an objection,
please let me know.

Thanks.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/6] mm/page_owner: use tackdepot to store stacktrace js1304@gmail.com - 2016-05-03 07:30 +0200
  [PATCH 5/6] tools/vm/page_owner: increase temporary buffer size js1304@gmail.com - 2016-05-03 07:30 +0200
  [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace js1304@gmail.com - 2016-05-03 07:30 +0200
    Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Michal Hocko <mhocko@kernel.org> - 2016-05-03 11:00 +0200
      Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-04 04:20 +0200
        Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-04 04:40 +0200
          Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Michal Hocko <mhocko@kernel.org> - 2016-05-04 11:30 +0200
            Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <js1304@gmail.com> - 2016-05-04 17:40 +0200
        Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Michal Hocko <mhocko@kernel.org> - 2016-05-04 11:30 +0200
          Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <js1304@gmail.com> - 2016-05-04 17:40 +0200
            Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <js1304@gmail.com> - 2016-05-04 17:50 +0200
              Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Michal Hocko <mhocko@kernel.org> - 2016-05-04 21:50 +0200
            Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Michal Hocko <mhocko@kernel.org> - 2016-05-04 21:50 +0200
              Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Joonsoo Kim <js1304@gmail.com> - 2016-05-10 09:10 +0200
                Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Michal Hocko <mhocko@kernel.org> - 2016-05-10 11:00 +0200
    Re: [PATCH 6/6] mm/page_owner: use stackdepot to store stacktrace Vlastimil Babka <vbabka@suse.cz> - 2016-05-12 14:00 +0200
  [PATCH 3/6] mm/page_owner: copy last_migrate_reason in copy_page_owner() js1304@gmail.com - 2016-05-03 07:30 +0200
    Re: [PATCH 3/6] mm/page_owner: copy last_migrate_reason in  copy_page_owner() Vlastimil Babka <vbabka@suse.cz> - 2016-05-10 17:20 +0200
      Re: [PATCH 3/6] mm/page_owner: copy last_migrate_reason in  copy_page_owner() Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-12 05:00 +0200
        Re: [PATCH 3/6] mm/page_owner: copy last_migrate_reason in  copy_page_owner() Vlastimil Babka <vbabka@suse.cz> - 2016-05-12 08:50 +0200
  [PATCH 4/6] mm/page_owner: introduce split_page_owner and replace manual handling js1304@gmail.com - 2016-05-03 07:30 +0200
    Re: [PATCH 4/6] mm/page_owner: introduce split_page_owner and replace  manual handling Vlastimil Babka <vbabka@suse.cz> - 2016-05-10 17:20 +0200
  [PATCH 2/6] mm/page_owner: initialize page owner without holding the zone lock js1304@gmail.com - 2016-05-03 07:30 +0200
    Re: [PATCH 2/6] mm/page_owner: initialize page owner without holding  the zone lock Vlastimil Babka <vbabka@suse.cz> - 2016-05-10 17:10 +0200
  [PATCH 1/6] mm/compaction: split freepages without holding the zone lock js1304@gmail.com - 2016-05-03 07:30 +0200
    Re: [PATCH 1/6] mm/compaction: split freepages without holding the  zone lock Vlastimil Babka <vbabka@suse.cz> - 2016-05-10 17:00 +0200
      Re: [PATCH 1/6] mm/compaction: split freepages without holding the  zone lock Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-12 05:00 +0200

csiph-web