On Tue, Dec 10, 2013 at 10:02:08AM -0800, Paul E. McKenney wrote:
> > > Should this be smp_mb__after_unlock_lock(); ?
> >
> > I think this is still ok. Minimally, it's missing the unlock/lock pair that
> > would cause smp_mb__after_unlock_lock() to be treated as a full barrier
> > on architectures
On Tue, Dec 10, 2013 at 05:19:36PM +, Mel Gorman wrote:
> On Tue, Dec 10, 2013 at 09:25:39AM -0500, Rik van Riel wrote:
> > On 12/09/2013 02:09 AM, Mel Gorman wrote:
> >
> > After reading the locking thread that Paul McKenney started,
> > I wonder if I got the barriers wrong in these functions
On Tue, Dec 10, 2013 at 09:25:39AM -0500, Rik van Riel wrote:
> On 12/09/2013 02:09 AM, Mel Gorman wrote:
>
> After reading the locking thread that Paul McKenney started,
> I wonder if I got the barriers wrong in these functions...
>
If Documentation/memory-barriers.txt could not be used to frig
From: Rik van Riel
There are a few subtle races, between change_protection_range (used by
mprotect and change_prot_numa) on one side, and NUMA page migration and
compaction on the other side.
The basic race is that there is a time window between when the PTE gets
made non-present (PROT_NONE or N
On 12/09/2013 02:09 AM, Mel Gorman wrote:
After reading the locking thread that Paul McKenney started,
I wonder if I got the barriers wrong in these functions...
> +#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
> +/*
> + * Memory barriers to keep this state in sync are gracious
From: Rik van Riel
There are a few subtle races, between change_protection_range (used by
mprotect and change_prot_numa) on one side, and NUMA page migration and
compaction on the other side.
The basic race is that there is a time window between when the PTE gets
made non-present (PROT_NONE or N
6 matches
Mail list logo
