Re: [PATCH v13 5/8] perf record: Read from overwritable ring buffer

From: Jiri Olsa
Date: Wed Jul 06 2016 - 08:34:20 EST


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

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

jirka