All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wangnan (F)" <wangnan0@huawei.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: <acme@kernel.org>, <linux-kernel@vger.kernel.org>,
	<pi3orama@163.com>, <lizefan@huawei.com>,
	He Kuang <hekuang@huawei.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Nilay Vaish <nilayvaish@gmail.com>
Subject: Re: [PATCH v13 5/8] perf record: Read from overwritable ring buffer
Date: Thu, 7 Jul 2016 12:59:41 +0800	[thread overview]
Message-ID: <577DE1BD.5020905@huawei.com> (raw)
In-Reply-To: <20160706123411.GF26517@krava>



On 2016/7/6 20:34, Jiri Olsa wrote:
> On Wed, Jul 06, 2016 at 08:03:28PM +0800, Wangnan (F) wrote:
>>
>> On 2016/7/6 19:38, Jiri Olsa wrote:
>>> On Mon, Jul 04, 2016 at 06:20:06AM +0000, Wang Nan wrote:
>>>
>>> SNIP
>>>
>>>> +static void
>>>> +record__toggle_overwrite_evsels(struct record *rec,
>>>> +				enum overwrite_evt_state state)
>>>> +{
>>>> +	struct perf_evlist *evlist = rec->overwrite_evlist;
>>>> +	enum overwrite_evt_state old_state = rec->overwrite_evt_state;
>>>> +	enum action {
>>>> +		NONE,
>>>> +		PAUSE,
>>>> +		RESUME,
>>>> +	} action = NONE;
>>>> +
>>>> +	switch (old_state) {
>>>> +	case OVERWRITE_EVT_RUNNING: {
>>>> +		switch (state) {
>>>> +		case OVERWRITE_EVT_DATA_PENDING:
>>>> +			action = PAUSE;
>>>> +			break;
>>>> +		case OVERWRITE_EVT_RUNNING:
>>>> +		case OVERWRITE_EVT_EMPTY:
>>>> +		default:
>>>> +			goto state_err;
>>>> +		}
>>>> +		break;
>>>> +	}
>>>> +	case OVERWRITE_EVT_DATA_PENDING: {
>>>> +		switch (state) {
>>>> +		case OVERWRITE_EVT_EMPTY:
>>>> +			break;
>>>> +		case OVERWRITE_EVT_RUNNING:
>>>> +		case OVERWRITE_EVT_DATA_PENDING:
>>>> +		default:
>>>> +			goto state_err;
>>>> +		}
>>>> +		break;
>>>> +	}
>>>> +	case OVERWRITE_EVT_EMPTY: {
>>>> +		switch (state) {
>>>> +		case OVERWRITE_EVT_RUNNING:
>>>> +			action = RESUME;
>>>> +			break;
>>>> +		case OVERWRITE_EVT_EMPTY:
>>>> +		case OVERWRITE_EVT_DATA_PENDING:
>>>> +		default:
>>>> +			goto state_err;
>>>> +		}
>>>> +		break;
>>>> +	}
>>>> +	default:
>>>> +		WARN_ONCE(1, "Shouldn't get there\n");
>>>> +	}
>>>> +
>>>> +	rec->overwrite_evt_state = state;
>>>> +
>>>> +	if (!evlist)
>>>> +		return;
>>> I'd expect this check at the begining
>> I think even evlist is NULL the state changing is still required.
>> Actually, the state machine is independent with aux evlist. Even
>> we without overwritable evsels the state machine is still valid.
>> So let the state machine runs unconditionally.
> hum, can't see that.. it's state machine to govern overwrite evlist, right?
> if there's no overwrite evlist we should keep the current processing

Not as easy as I thought. Look at following code:

>@@ -1006,8 +1122,27 @@ static int __cmd_record(struct record *rec, int argc, const char **argv)
> 		}
>
> 		if (trigger_is_hit(&switch_output_trigger)) {
>+			/*
>+			 * If switch_output_trigger is hit, the data in
>+			 * overwritable ring buffer should have been collected,
>+			 * so overwrite_evt_state should be set to
>+			 * OVERWRITE_EVT_EMPTY.
>+			 *
>+			 * If SIGUSR2 raise after or during record__mmap_read_all(),
>+			 * record__mmap_read_all() didn't collect data from
>+			 * overwritable ring buffer. Read again.
>+			 */
>+			if (rec->overwrite_evt_state == OVERWRITE_EVT_RUNNING)
>+				continue;
> 			trigger_ready(&switch_output_trigger);
>
>+			/*
>+			 * Reenable events in overwrite ring buffer after
>+			 * record__mmap_read_all(): we should have collected
>+			 * data from it.
>+			 */
>+			record__toggle_overwrite_evsels(rec, OVERWRITE_EVT_RUNNING);
>+
> 			if (!quiet)
> 				fprintf(stderr, "[ perf record: dump data: Woken up %ld times ]\n",
> 					waking);

Here perf tests whether reading from overwritable ring buffer is required.
If SIGUSR2 is received just before the above trigger_is_hit, we should 
read from
overwrite ring buffer again. The OVERWRITE_EVT_RUNNING checker is for 
this reason.

Now if we stop the state machine, the state is stopped at 
OVERWRITE_EVT_RUNNING,
causes perf loops forever.

We can check rec->overwrite_evlist first, but it is ugly, since I 
believe the
overwritable state is independent to overwrite evlist. So I decide to 
introduce
a new state indicate the overwrite evlist is not ready.

Thank you.


> if it's meant to govern the mmap reading in general
> we should at least rename it
> jirka

  reply	other threads:[~2016-07-07  5:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04  6:20 [PATCH v13 0/8] perf tools: Support overwritable ring buffer Wang Nan
2016-07-04  6:20 ` [PATCH v13 1/8] perf tools: Drop redundant evsel->overwrite indicator Wang Nan
2016-07-06 10:53   ` Jiri Olsa
2016-07-06 10:55     ` Wangnan (F)
2016-07-04  6:20 ` [PATCH v13 2/8] perf evlist: Introduce aux evlist Wang Nan
2016-07-06 11:36   ` Jiri Olsa
2016-07-06 12:16     ` Wangnan (F)
2016-07-08 14:46       ` Jiri Olsa
2016-07-11 10:20         ` Wangnan (F)
2016-07-04  6:20 ` [PATCH v13 3/8] perf tests: Add testcase for auxiliary evlist Wang Nan
2016-07-04  6:20 ` [PATCH v13 4/8] perf record: Introduce rec->overwrite_evlist for overwritable events Wang Nan
2016-07-04  6:20 ` [PATCH v13 5/8] perf record: Read from overwritable ring buffer Wang Nan
2016-07-06 11:37   ` Jiri Olsa
2016-07-06 11:38   ` Jiri Olsa
2016-07-06 12:03     ` Wangnan (F)
2016-07-06 12:34       ` Jiri Olsa
2016-07-07  4:59         ` Wangnan (F) [this message]
2016-07-04  6:20 ` [PATCH v13 6/8] perf tools: Enable overwrite settings Wang Nan
2016-07-04  6:20 ` [PATCH v13 7/8] perf tools: Don't warn about out of order event if write_backward is used Wang Nan
2016-07-04  6:20 ` [PATCH v13 8/8] perf tools: Add --tail-synthesize option Wang Nan

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=577DE1BD.5020905@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=hekuang@huawei.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mhiramat@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=nilayvaish@gmail.com \
    --cc=pi3orama@163.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.