From: Andrew Morton <akpm@linux-foundation.org>
To: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>, Shaohua Li <shli@fb.com>,
linux-mm@kvack.org, linux-kernel <linux-kernel@vger.kernel.org>,
kernel-team@fb.com
Subject: Re: [PATCH] proc: revert /proc/<pid>/maps [stack:TID] annotation
Date: Tue, 19 Jan 2016 21:27:45 -0800 [thread overview]
Message-ID: <20160119212745.eee310f5.akpm@linux-foundation.org> (raw)
In-Reply-To: <CAAHN_R2CFYsSSU_Qr-_cE+9-=OqDOa88annh9uA1TymuJncL8A@mail.gmail.com>
On Wed, 20 Jan 2016 08:47:39 +0530 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> wrote:
> On 20 January 2016 at 03:44, Andrew Morton <akpm@linux-foundation.org> wrote:
> > Any thoughts on the obvious back-compatibility concerns? ie, why did
> > Siddhesh implement this in the first place? My bad for not ensuring
> > that the changelog told us this.
> >
> > https://lkml.org/lkml/2012/1/14/25 has more info:
> >
> > : Memory mmaped by glibc for a thread stack currently shows up as a
> > : simple anonymous map, which makes it difficult to differentiate between
> > : memory usage of the thread on stack and other dynamic allocation.
> > : Since glibc already uses MAP_STACK to request this mapping, the
> > : attached patch uses this flag to add additional VM_STACK_FLAGS to the
> > : resulting vma so that the mapping is treated as a stack and not any
> > : regular anonymous mapping. Also, one may use vm_flags to decide if a
> > : vma is a stack.
> >
> > But even that doesn't really tell us what the actual *value* of the
> > patch is to end-users.
>
> The end users needed a way to identify thread stacks programmatically
> and there wasn't a way to do that. I'm afraid I no longer remember
> (or have access to the resources that would aid my memory since I
> changed employers) the details of their requirement. However, I did
> do this on my own time because I thought it was an interesting project
> for me and nobody really gave any feedback then as to its utility, so
> as far as I am concerned you could roll back the main thread maps
> information since the information is available in the thread-specific
> files.
OK, thanks. I was thinking of queueing this for 4.6 to let it bake in
-next for a cycle, but quadratic performance is bad and nobody will
test such an obscure feature in -next so maybe I'll jam it into 4.5 and we
wait and see.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>, Shaohua Li <shli@fb.com>,
linux-mm@kvack.org, linux-kernel <linux-kernel@vger.kernel.org>,
kernel-team@fb.com
Subject: Re: [PATCH] proc: revert /proc/<pid>/maps [stack:TID] annotation
Date: Tue, 19 Jan 2016 21:27:45 -0800 [thread overview]
Message-ID: <20160119212745.eee310f5.akpm@linux-foundation.org> (raw)
In-Reply-To: <CAAHN_R2CFYsSSU_Qr-_cE+9-=OqDOa88annh9uA1TymuJncL8A@mail.gmail.com>
On Wed, 20 Jan 2016 08:47:39 +0530 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> wrote:
> On 20 January 2016 at 03:44, Andrew Morton <akpm@linux-foundation.org> wrote:
> > Any thoughts on the obvious back-compatibility concerns? ie, why did
> > Siddhesh implement this in the first place? My bad for not ensuring
> > that the changelog told us this.
> >
> > https://lkml.org/lkml/2012/1/14/25 has more info:
> >
> > : Memory mmaped by glibc for a thread stack currently shows up as a
> > : simple anonymous map, which makes it difficult to differentiate between
> > : memory usage of the thread on stack and other dynamic allocation.
> > : Since glibc already uses MAP_STACK to request this mapping, the
> > : attached patch uses this flag to add additional VM_STACK_FLAGS to the
> > : resulting vma so that the mapping is treated as a stack and not any
> > : regular anonymous mapping. Also, one may use vm_flags to decide if a
> > : vma is a stack.
> >
> > But even that doesn't really tell us what the actual *value* of the
> > patch is to end-users.
>
> The end users needed a way to identify thread stacks programmatically
> and there wasn't a way to do that. I'm afraid I no longer remember
> (or have access to the resources that would aid my memory since I
> changed employers) the details of their requirement. However, I did
> do this on my own time because I thought it was an interesting project
> for me and nobody really gave any feedback then as to its utility, so
> as far as I am concerned you could roll back the main thread maps
> information since the information is available in the thread-specific
> files.
OK, thanks. I was thinking of queueing this for 4.6 to let it bake in
-next for a cycle, but quadratic performance is bad and nobody will
test such an obscure feature in -next so maybe I'll jam it into 4.5 and we
wait and see.
next prev parent reply other threads:[~2016-01-20 5:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 18:02 [PATCH] proc: revert /proc/<pid>/maps [stack:TID] annotation Johannes Weiner
2016-01-19 18:02 ` Johannes Weiner
2016-01-19 22:14 ` Andrew Morton
2016-01-19 22:14 ` Andrew Morton
2016-01-19 23:30 ` Kirill A. Shutemov
2016-01-19 23:30 ` Kirill A. Shutemov
2016-01-20 3:21 ` Siddhesh Poyarekar
2016-01-20 3:21 ` Siddhesh Poyarekar
2016-01-19 23:38 ` Johannes Weiner
2016-01-19 23:38 ` Johannes Weiner
2016-01-20 3:17 ` Siddhesh Poyarekar
2016-01-20 3:17 ` Siddhesh Poyarekar
2016-01-20 5:27 ` Andrew Morton [this message]
2016-01-20 5:27 ` Andrew Morton
2016-01-21 10:49 ` [PATCH] proc: add missing 'mm' variable in nommu is_stack() Arnd Bergmann
2016-01-21 10:49 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2016-01-25 21:30 [PATCH] proc: revert /proc/<pid>/maps [stack:TID] annotation Colin Cross
2016-01-25 21:30 ` Colin Cross
2016-01-25 23:14 ` Kirill A. Shutemov
2016-01-25 23:14 ` Kirill A. Shutemov
2016-01-25 23:53 ` Colin Cross
2016-01-25 23:53 ` Colin Cross
2016-01-28 10:25 ` Kirill A. Shutemov
2016-01-28 10:25 ` Kirill A. Shutemov
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=20160119212745.eee310f5.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shli@fb.com \
--cc=siddhesh.poyarekar@gmail.com \
/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.