On Fri, 18 Jan 2013, Steven Rostedt wrote: > On Fri, 2013-01-18 at 10:04 -0500, Steven Rostedt wrote: > > Just to be more complete: > > > CPU0 CPU1 > > ---- ---- > c = __this_cpu_ptr(s->cpu_slab); > <migrates to CPU0> > > > <cpu fetches c->page> > <another task> > > > updates c->tid We can avoid the above scenario by doing a cpu local fetch. i.e. ` tid = this_cpu_read(s->cpu_slab->tid); > > updates c->page > > updates c->freelist > > <cpu fetches c->tid> > > <cpu fetches c->freelist> > > > > node_match() succeeds even though > > current c->page wont > > > > <migrates back to CPU 1> > > > this_cpu_cmpxchg_double() only tests > > the object (freelist) and tid, both which > > will match, but the page that was tested > > isn't the right one. > > > > Yes, it's very unlikely, but we are in the business of dealing with the > very unlikely. That's because in our business, the very unlikely is very > likely. Damn, I need to buy a lotto ticket! Well, the consequence would be that an object from another node than desired will be allocated. Not that severe of an issue. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
