All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Maninder Singh <maninder1.s@samsung.com>,
	"kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"jkosina@suse.cz" <jkosina@suse.cz>,
	"pombredanne@nexb.com" <pombredanne@nexb.com>,
	"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"guptap@codeaurora.org" <guptap@codeaurora.org>,
	"vinmenon@codeaurora.org" <vinmenon@codeaurora.org>,
	AMIT SAHRAWAT <a.sahrawat@samsung.com>,
	PANKAJ MISHRA <pankaj.m@samsung.com>,
	Lalit Mohan Tripathi <lalit.mohan@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Vaneet Narang <v.narang@samsung.com>,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.
Date: Fri, 24 Nov 2017 11:23:08 +0100	[thread overview]
Message-ID: <CACT4Y+bF7TGFS+395kyzdw21M==ECgs+dCjV0e3Whkvm1_piDA@mail.gmail.com> (raw)
In-Reply-To: <20171124095428.5ojzgfd24sy7zvhe@dhcp22.suse.cz>

On Fri, Nov 24, 2017 at 10:54 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Fri 24-11-17 09:41:08, Maninder Singh wrote:
>> Hi Michal,
>>
>> > On Wed 22-11-17 16:17:41, Maninder Singh wrote:
>> > > This patch provides interface to check all the stack enteries
>> > > saved in stackdepot so far as well as memory consumed by stackdepot.
>> > >
>> > > 1) Take current depot_index and offset to calculate end address for one
>> > >         iteration of (/sys/kernel/debug/depot_stack/depot_entries).
>> > >
>> > > 2) Fill end marker in every slab to point its end, and then use it while
>> > >         traversing all the slabs of stackdepot.
>> > >
>> > > "debugfs code inspired from page_onwer's way of printing BT"
>> > >
>> > > checked on ARM and x86_64.
>> > > $cat /sys/kernel/debug/depot_stack/depot_size
>> > > Memory consumed by Stackdepot:208 KB
>> > >
>> > > $ cat /sys/kernel/debug/depot_stack/depot_entries
>> > > stack count 1 backtrace
>> > >  init_page_owner+0x1e/0x210
>> > >  start_kernel+0x310/0x3cd
>> > >  secondary_startup_64+0xa5/0xb0
>> > >  0xffffffffffffffff
>> >
>> > Why do we need this? Who is goging to use this information and what for?
>> > I haven't looked at the code but just the diffstat looks like this
>> > should better have a _very_ good justification to be considered for
>> > merging. To be honest with you I have hard time imagine how this can be
>> > useful other than debugging stack depot...
>>
>> This interface can be used for multiple reasons as:
>>
>> 1) For debugging stackdepot for sure.
>> 2) For checking all the unique allocation paths in system.
>> 3) To check if any invalid stack is coming which is increasing
>> stackdepot memory.
>> (https://lkml.org/lkml/2017/10/11/353)
>
> OK, so debugging a debugging facility... I do not think we want to
> introduce a lot of code for something like that.
>
>> Althoutgh this needs to be taken care in ARM as replied by maintainer, but with help
>> of this interface it was quite easy to check and we added workaround for saving memory.
>>
>> 4) At some point of time to check current memory consumed by stackdepot.
>> 5) To check number of entries in stackdepot to decide stackdepot hash size for different systems.
>>    For fewer entries hash table size can be reduced from 4MB.
>
> What are you going to do with that information. It is not like you can
> reduce the memory footprint or somehow optimize anything during the
> runtime.
>
> --
> Michal Hocko
> SUSE Labs

+kasan-dev mailing list

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Vyukov <dvyukov@google.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Maninder Singh <maninder1.s@samsung.com>,
	"kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"jkosina@suse.cz" <jkosina@suse.cz>,
	"pombredanne@nexb.com" <pombredanne@nexb.com>,
	"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"guptap@codeaurora.org" <guptap@codeaurora.org>,
	"vinmenon@codeaurora.org" <vinmenon@codeaurora.org>,
	AMIT SAHRAWAT <a.sahrawat@samsung.com>,
	PANKAJ MISHRA <pankaj.m@samsung.com>,
	Lalit Mohan Tripathi <lalit.mohan@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Vaneet Narang <v.narang@samsung.com>,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.
Date: Fri, 24 Nov 2017 11:23:08 +0100	[thread overview]
Message-ID: <CACT4Y+bF7TGFS+395kyzdw21M==ECgs+dCjV0e3Whkvm1_piDA@mail.gmail.com> (raw)
In-Reply-To: <20171124095428.5ojzgfd24sy7zvhe@dhcp22.suse.cz>

On Fri, Nov 24, 2017 at 10:54 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Fri 24-11-17 09:41:08, Maninder Singh wrote:
>> Hi Michal,
>>
>> > On Wed 22-11-17 16:17:41, Maninder Singh wrote:
>> > > This patch provides interface to check all the stack enteries
>> > > saved in stackdepot so far as well as memory consumed by stackdepot.
>> > >
>> > > 1) Take current depot_index and offset to calculate end address for one
>> > >         iteration of (/sys/kernel/debug/depot_stack/depot_entries).
>> > >
>> > > 2) Fill end marker in every slab to point its end, and then use it while
>> > >         traversing all the slabs of stackdepot.
>> > >
>> > > "debugfs code inspired from page_onwer's way of printing BT"
>> > >
>> > > checked on ARM and x86_64.
>> > > $cat /sys/kernel/debug/depot_stack/depot_size
>> > > Memory consumed by Stackdepot:208 KB
>> > >
>> > > $ cat /sys/kernel/debug/depot_stack/depot_entries
>> > > stack count 1 backtrace
>> > >  init_page_owner+0x1e/0x210
>> > >  start_kernel+0x310/0x3cd
>> > >  secondary_startup_64+0xa5/0xb0
>> > >  0xffffffffffffffff
>> >
>> > Why do we need this? Who is goging to use this information and what for?
>> > I haven't looked at the code but just the diffstat looks like this
>> > should better have a _very_ good justification to be considered for
>> > merging. To be honest with you I have hard time imagine how this can be
>> > useful other than debugging stack depot...
>>
>> This interface can be used for multiple reasons as:
>>
>> 1) For debugging stackdepot for sure.
>> 2) For checking all the unique allocation paths in system.
>> 3) To check if any invalid stack is coming which is increasing
>> stackdepot memory.
>> (https://lkml.org/lkml/2017/10/11/353)
>
> OK, so debugging a debugging facility... I do not think we want to
> introduce a lot of code for something like that.
>
>> Althoutgh this needs to be taken care in ARM as replied by maintainer, but with help
>> of this interface it was quite easy to check and we added workaround for saving memory.
>>
>> 4) At some point of time to check current memory consumed by stackdepot.
>> 5) To check number of entries in stackdepot to decide stackdepot hash size for different systems.
>>    For fewer entries hash table size can be reduced from 4MB.
>
> What are you going to do with that information. It is not like you can
> reduce the memory footprint or somehow optimize anything during the
> runtime.
>
> --
> Michal Hocko
> SUSE Labs

+kasan-dev mailing list

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

  reply	other threads:[~2017-11-24 10:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcas5p1.samsung.com>
2017-11-22 10:47 ` [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot Maninder Singh
2017-11-22 10:47   ` Maninder Singh
2017-11-23 16:28   ` Michal Hocko
2017-11-23 16:28     ` Michal Hocko
     [not found]   ` <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcms5p3>
2017-11-24  9:41     ` Maninder Singh
2017-11-24  9:41       ` Maninder Singh
2017-11-24  9:54       ` Michal Hocko
2017-11-24  9:54         ` Michal Hocko
2017-11-24 10:23         ` Dmitry Vyukov [this message]
2017-11-24 10:23           ` Dmitry Vyukov
     [not found]         ` <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcms5p4>
2017-11-24 11:57           ` Vaneet Narang
2017-11-24 11:57             ` Vaneet Narang
2017-11-24 12:44             ` Michal Hocko
2017-11-24 12:44               ` Michal Hocko
     [not found]             ` <CGME20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665@epcms5p7>
2017-11-24 13:30               ` Vaneet Narang
2017-11-24 13:30                 ` Vaneet Narang
2017-11-24 13:48                 ` Michal Hocko
2017-11-24 13:48                   ` Michal Hocko
2017-11-28  3:37                 ` Vinayak Menon
2017-11-28  3:37                   ` Vinayak Menon

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='CACT4Y+bF7TGFS+395kyzdw21M==ECgs+dCjV0e3Whkvm1_piDA@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=a.sahrawat@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guptap@codeaurora.org \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=lalit.mohan@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maninder1.s@samsung.com \
    --cc=mhocko@kernel.org \
    --cc=pankaj.m@samsung.com \
    --cc=pombredanne@nexb.com \
    --cc=v.narang@samsung.com \
    --cc=vbabka@suse.cz \
    --cc=vinmenon@codeaurora.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: link
Be 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.