All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org, kan.liang@intel.com
Subject: Re: UI messages in event thread hangs perf top
Date: Mon, 29 Oct 2018 09:25:28 -0300	[thread overview]
Message-ID: <20181029122528.GA20813@kernel.org> (raw)
In-Reply-To: <20181027.205830.1547905692901578490.davem@davemloft.net>

Em Sat, Oct 27, 2018 at 08:58:30PM -0700, David Miller escreveu:
> 
> If I run perf top with a "make -j128" kernel build, I get ring buffer event
> processing timeouts which results in:
> 
> 		ui__warning("Too slow to read ring buffer.\n"
> 			    "Please try increasing the period (-c) or\n"
> 			    "decreasing the freq (-F) or\n"
> 			    "limiting the number of CPUs (-C)\n");
> 
> from perf_top__mmap_read().
> 
> This hangs the main event thread.  Only the display thread runs after
> this point.
> 
> We can't issue UI messages from the event thread, because those will
> hang waiting for a keypress.  The display thread will eat any keys
> we press and the event thread thus hangs forever.
> 
> I can tell this is what has happened because the histogram entries
> continue to decay, yet the event count stops increasing.
> 
> If I put a gdb on the perf process, indeed the backtrace in the event
> processing thread is in the select() call done by ui__getch().
> 
> Adding insult to injury, the display thread immediately overwrites the
> warning message printed by the event thread, and thus the user has no
> chance to even see it.
> 
> I really wonder how this was tested.
> 
> Perhaps we should mark the event thread in a special way and trigger
> assertions if UI messages are printed from it.  Again, any such
> operation will hang the thread and stop all event processing.

Right, I thought about marking a flag in the main event thread that then
gets picked up by the display thread, I'll try and write a patch for
that, if none has been submitted, I'm still downloading this weekend's
messages.

- Arnaldo

P.S. I was busy working as a volunteer in the brazilian elections :-\

      reply	other threads:[~2018-10-29 12:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-28  3:58 UI messages in event thread hangs perf top David Miller
2018-10-29 12:25 ` Arnaldo Carvalho de Melo [this message]

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=20181029122528.GA20813@kernel.org \
    --to=acme@kernel.org \
    --cc=davem@davemloft.net \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.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.