Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Oct 2010 14:45:03 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        freebsd-hackers@freebsd.org
Cc:        Matthew Fleming <mdf@freebsd.org>, Andriy Gapon <avg@freebsd.org>
Subject:   Re: generic_stop_cpus: prevent parallel execution
Message-ID:  <201010111445.14920.jkim@FreeBSD.org>
In-Reply-To: <201010111211.37993.jhb@freebsd.org>
References:  <4CAE092A.60905@freebsd.org> <201010111211.37993.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 11 October 2010 12:11 pm, John Baldwin wrote:
> On Thursday, October 07, 2010 1:53:46 pm Andriy Gapon wrote:
> > Here is patch that applies the technique from panic() to
> > generic_stop_cpus() to prevent its parallel execution on multiple
> > CPUs:
> > http://people.freebsd.org/~avg/generic_stop_cpus.diff
> >
> > In theory this could lead to two CPUs stopping each other and
> > everyone else, and thus a total system halt.
> >
> > Also, in theory, we should have some smarter locking here,
> > because two (or more CPUs) could be stopping unrelated sets of
> > CPUs.  But in practice, it seems, this function is only used to
> > stop "all other" CPUs.  Unless I overlooked other usages, that
> > is.
> >
> > Additionally, I took this opportunity to make amd64-specific
> > suspend_cpus() function use generic_stop_cpus() instead of
> > rolling out essentially duplicate code.  I couldn't see any
> > reason no to consolidate, but perhaps I missed something.

When I wrote the code, generic_stop_cpus() didn't exist.  Now it makes 
sense, though.

> > Big thanks to Matthew and his employer for the idea and example.
>
> One note.  Use 'cpu_spinwait()' in the inner loop waiting for
> 'stopping_cpu' to change.

+1.

Jung-uk Kim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010111445.14920.jkim>