On Thu, 8 Jan 2015, Joonsoo Kim wrote:
> > You'd need a smp_wmb() in between tid and c in the loop then, which
> > looks quite unpleasant. All in all disabling preemption isn't really
> > that expensive, and you should redo your performance number if you go
> > this way.
>
> This barrier() is not
On Tue, Jan 06, 2015 at 09:02:17AM -0800, Davidlohr Bueso wrote:
> On Tue, 2015-01-06 at 17:09 +0900, Joonsoo Kim wrote:
> > On Mon, Jan 05, 2015 at 07:03:12PM -0800, Davidlohr Bueso wrote:
> > > On Mon, 2015-01-05 at 10:36 +0900, Joonsoo Kim wrote:
> > > > - preempt_disable();
> > > > -
On Tue, 2015-01-06 at 17:09 +0900, Joonsoo Kim wrote:
> On Mon, Jan 05, 2015 at 07:03:12PM -0800, Davidlohr Bueso wrote:
> > On Mon, 2015-01-05 at 10:36 +0900, Joonsoo Kim wrote:
> > > - preempt_disable();
> > > - c = this_cpu_ptr(s->cpu_slab);
> > > + do {
> > > + tid = this_cpu_read(s->cp
On Mon, Jan 05, 2015 at 09:25:02PM -0500, Steven Rostedt wrote:
> On Tue, 6 Jan 2015 10:32:47 +0900
> Joonsoo Kim wrote:
>
>
> > > > +++ b/mm/slub.c
> > > > @@ -2398,13 +2398,15 @@ redo:
> > > > * reading from one cpu area. That does not matter as long
> > > > * as we end up on
On Mon, Jan 05, 2015 at 07:03:12PM -0800, Davidlohr Bueso wrote:
> On Mon, 2015-01-05 at 10:36 +0900, Joonsoo Kim wrote:
> > - preempt_disable();
> > - c = this_cpu_ptr(s->cpu_slab);
> > + do {
> > + tid = this_cpu_read(s->cpu_slab->tid);
> > + c = this_cpu_ptr(s->cpu_slab
On Mon, 2015-01-05 at 10:36 +0900, Joonsoo Kim wrote:
> - preempt_disable();
> - c = this_cpu_ptr(s->cpu_slab);
> + do {
> + tid = this_cpu_read(s->cpu_slab->tid);
> + c = this_cpu_ptr(s->cpu_slab);
> + } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c
On Tue, 6 Jan 2015 10:32:47 +0900
Joonsoo Kim wrote:
> > > +++ b/mm/slub.c
> > > @@ -2398,13 +2398,15 @@ redo:
> > >* reading from one cpu area. That does not matter as long
> > >* as we end up on the original cpu again when doing the cmpxchg.
> > >*
> > > - * Preemption is disabled
On Mon, Jan 05, 2015 at 04:37:35PM +0800, Hillf Danton wrote:
> >
> > We had to insert a preempt enable/disable in the fastpath a while ago
> > in order to guarantee that tid and kmem_cache_cpu are retrieved on the
> > same cpu. It is the problem only for CONFIG_PREEMPT in which scheduler
> > can
On Mon, 5 Jan 2015, Joonsoo Kim wrote:
> Now, I reach the solution to remove preempt enable/disable in the fastpath.
> If tid is matched with kmem_cache_cpu's tid after tid and kmem_cache_cpu
> are retrieved by separate this_cpu operation, it means that they are
> retrieved on the same cpu. If not
>
> We had to insert a preempt enable/disable in the fastpath a while ago
> in order to guarantee that tid and kmem_cache_cpu are retrieved on the
> same cpu. It is the problem only for CONFIG_PREEMPT in which scheduler
> can move the process to other cpu during retrieving data.
>
> Now, I reach
We had to insert a preempt enable/disable in the fastpath a while ago
in order to guarantee that tid and kmem_cache_cpu are retrieved on the
same cpu. It is the problem only for CONFIG_PREEMPT in which scheduler
can move the process to other cpu during retrieving data.
Now, I reach the solution to
11 matches
Mail list logo
