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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>