public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alex Neronskiy <zakmagnus@chromium.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Don Zickus <dzickus@redhat.com>,
	Mandeep Singh Baines <msb@chromium.org>,
	Alex Neronskiy <zakmagnus@chromium.com>
Subject: Re: [PATCH v6 2/2] Output stall data in debugfs
Date: Thu, 11 Aug 2011 21:35:22 +0200	[thread overview]
Message-ID: <1313091323.8491.30.camel@twins> (raw)
In-Reply-To: <1312999364-21104-2-git-send-email-zakmagnus@chromium.org>

On Wed, 2011-08-10 at 11:02 -0700, Alex Neronskiy wrote:
> @@ -210,22 +236,27 @@ void touch_softlockup_watchdog_sync(void)
>  /* watchdog detector functions */
>  static void update_hardstall(unsigned long stall, int this_cpu)
>  {
>         if (stall > hardstall_thresh && stall > worst_hardstall) {
>                 unsigned long flags;
> +               spin_lock_irqsave(&hardstall_write_lock, flags);
> +               if (stall > worst_hardstall) {
> +                       int write_ind = hard_read_ind;
> +                       int locked = spin_trylock(&hardstall_locks[write_ind]);
> +                       /* cannot wait, so if there's contention,
> +                        * switch buffers */
> +                       if (!locked)
> +                               write_ind = !write_ind;
> +
>                         worst_hardstall = stall;
> +                       hardstall_traces[write_ind].nr_entries = 0;
> +                       save_stack_trace(&hardstall_traces[write_ind]);
>  
> +                       /* tell readers to use the new buffer from now on */
> +                       hard_read_ind = write_ind;
> +                       if (locked)
> +                               spin_unlock(&hardstall_locks[write_ind]);
> +               }
> +               spin_unlock_irqrestore(&hardstall_write_lock, flags);
>         }
>  } 

That must be the most convoluted locking I've seen in a while.. OMG!

What's wrong with something like:

static void update_stall(struct stall *s, unsigned long stall)
{
	if (stall <= s->worst)
		return;

again:
	if (!raw_spin_trylock(&s->lock[s->idx])) {
		s->idx ^= 1;
		goto again;
	}

	if (stall <= s->worst)
		goto unlock;

	s->worst = stall;
	s->trace[s->idx].nr_entries = 0;
	save_stack_trace(&s->trace[s->idx]);

unlock:
	raw_spin_unlock(&s->lock[s->idx]);
}


And have your read side do:


static void show_stall_trace(struct seq_file *f, void *v)
{
	struct stall *s = f->private;
	int i, idx = ACCESS_ONCE(s->idx);

	mutex_lock(&stall_mutex);

	raw_spin_lock(&s->lock[idx]);
	seq_printf(f, "stall: %d\n", s->worst);
	for (i = 0; i < s->trace[idx].nr_entries; i++) {
		seq_printf(f, "[<%pK>] %pS\n", 
			(void *)s->trace->entries[i],
			(void *)s->trace->entries[i]);
	}
	raw_spin_unlock(&s->lock[idx]);

	mutex_unlock(&stall_mutex);
}


Yes its racy on s->worst, but who cares (if you do care you can keep a
copy in s->delay[idx] or so). Also, it might be better to not do the
spinlock but simply use an atomic bitop to set an in-use flag, there is
no reason to disable preemption over the seq_printf() loop.



  parent reply	other threads:[~2011-08-11 19:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 18:02 [PATCH v6 1/2] Track hard and soft "short lockups" or "stalls." Alex Neronskiy
2011-08-10 18:02 ` [PATCH v6 2/2] Output stall data in debugfs Alex Neronskiy
2011-08-11 18:48   ` Andi Kleen
2011-08-11 19:04     ` Don Zickus
2011-08-11 21:05       ` Andi Kleen
2011-08-11 19:13   ` Peter Zijlstra
2011-08-11 19:35   ` Peter Zijlstra [this message]
2011-08-11 20:10     ` Alex Neronskiy
2011-08-11 20:23       ` Peter Zijlstra
2011-08-11 20:31         ` Alex Neronskiy
2011-08-11 21:17           ` Peter Zijlstra
2011-08-11 22:02             ` Alex Neronskiy
2011-08-11 23:00             ` Mandeep Singh Baines
2011-08-12 12:14               ` Peter Zijlstra
2011-08-16 19:32                 ` Mandeep Singh Baines
2011-08-12  9:06     ` Ingo Molnar
2011-08-12 19:46       ` Alex Neronskiy
2011-08-11 19:43   ` Peter Zijlstra
2011-08-11 19:51     ` Alex Neronskiy
2011-08-11 19:57       ` Peter Zijlstra
2011-08-11 19:09 ` [PATCH v6 1/2] Track hard and soft "short lockups" or "stalls." Peter Zijlstra

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=1313091323.8491.30.camel@twins \
    --to=peterz@infradead.org \
    --cc=dzickus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=msb@chromium.org \
    --cc=zakmagnus@chromium.com \
    --cc=zakmagnus@chromium.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