From: Stephane Eranian <eranian@google.com>
To: willy@infradead.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
hch@infradead.org, Alexander Viro <viro@zeniv.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, "Luck, Tony" <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: perfmon trouble
Date: Mon, 11 Jun 2018 11:51:34 -0700 [thread overview]
Message-ID: <CABPqkBTwqtFxtFsCjTNyHa_T1_vCbCQWHwo42RZAbg0QRi1BFw@mail.gmail.com> (raw)
In-Reply-To: <20180611171811.GB28292@bombadil.infradead.org>
Hi,
On Mon, Jun 11, 2018 at 10:18 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Mon, Jun 11, 2018 at 10:04:00AM -0700, Linus Torvalds wrote:
> > On Mon, Jun 11, 2018 at 9:49 AM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > The problem is that even oprofile on ia64 depends on perfmon.
> >
> > Hmm? You can definitely enable ia64 support for oprofile even without perfmon.
>
> Oh, I think my memory is playing tricks on me. This is my confusion, I think:
>
> oprofile-$(CONFIG_PERFMON) += perfmon.o
>
> so perfmon events are exposed through oprofile, but you can disable
> perfmon without disabling oprofile.
>
> > Because I'd be inclined to just remove CONFIG_PERFMON support, and see
> > if anybody even notices..
> >
> > I'm not expecting a lot of people to do a lot of oprofile on ia64
> > anyway. It's a bit late to start optimizing things now.
> >
> > Do people use perfmon still? Maybe. Maybe not. Perhaps we could just
> > mark it as broken in the Kconfig file for now, and see if somebody
> > says something?
>
Thanks Al for the careful analysis. If I understand correctly, the
problem seems to be that on
execve the mapping of the sampling buffer is not destroyed and then on
close, the kernel
unmaps whatever the new binary had in that address range. The fix
would be to ensure
the mmap is destroyed on execve.
My problem is that I do not have IA64 hw anymore, so whatever the fix,
I will not be able
to test this. In the meantime, I agree with Matthew, simply disable
PERFMON support.
thanks.
> That gets my vote.
>
> Tony? Fenghua?
>
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 792437d526c6..ff861420b8f5 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -455,6 +455,7 @@ config IA64_MCA_RECOVERY
>
> config PERFMON
> bool "Performance monitor support"
> + depends on BROKEN
> help
> Selects whether support for the IA-64 performance monitor hardware
> is included in the kernel. This makes some kernel data-structures a
>
next prev parent reply other threads:[~2018-06-11 18:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-08 18:48 [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends Al Viro
2018-06-08 18:50 ` [PATCH 01/13] drm_mode_create_lease_ioctl(): switch to filp_clone_open() Al Viro
2018-06-08 18:50 ` [PATCH 02/13] rename filp_clone_open() to file_clone_open() Al Viro
2018-06-08 18:50 ` [PATCH 03/13] introduce FMODE_OPENED Al Viro
2018-06-08 18:50 ` [PATCH 04/13] get rid of 'opened' argument of finish_open() Al Viro
2018-06-08 18:50 ` [PATCH 05/13] pull fput() on late failures into path_openat() Al Viro
2018-06-08 18:50 ` [PATCH 06/13] switch all remaining checks for FILE_OPENED to FMODE_OPENED Al Viro
2018-06-08 18:50 ` [PATCH 07/13] now we can fold open_check_o_direct() into do_dentry_open() Al Viro
2018-06-08 18:50 ` [PATCH 08/13] __gfs2_lookup(), nfs_finish_open() and fuse_create_open() don't need 'opened' Al Viro
2018-06-08 18:50 ` [PATCH 09/13] introduce FMODE_CREATED and switch to it Al Viro
2018-06-08 18:50 ` [PATCH 10/13] IMA: don't propagate opened through the entire thing Al Viro
2018-06-08 18:50 ` [PATCH 11/13] gfs2_create_inode() doesn't need 'opened' anymore Al Viro
2018-06-08 18:50 ` [PATCH 12/13] get rid of 'opened' argument of ->atomic_open() Al Viro
2018-06-08 18:50 ` [PATCH 13/13] get rid of 'opened' in path_openat() and the helpers downstream Al Viro
2018-06-08 18:57 ` [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends Linus Torvalds
2018-06-09 5:10 ` Al Viro
2018-06-09 15:51 ` Al Viro
2018-06-11 2:10 ` perfmon trouble Al Viro
2018-06-11 16:23 ` Christoph Hellwig
2018-06-11 16:48 ` Matthew Wilcox
2018-06-11 17:04 ` Linus Torvalds
2018-06-11 17:18 ` Matthew Wilcox
2018-06-11 18:51 ` Stephane Eranian [this message]
2018-06-11 18:59 ` Linus Torvalds
2018-06-11 20:06 ` Al Viro
2018-06-17 18:22 ` [RFC][PATCHES] getting rid of int *open in ->atomic_open() and friends Al Viro
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=CABPqkBTwqtFxtFsCjTNyHa_T1_vCbCQWHwo42RZAbg0QRi1BFw@mail.gmail.com \
--to=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).