Re: [RFC PATCH] percpu system call: fast userspace percpu critical sections

From: Christoph Lameter
Date: Fri May 29 2015 - 12:46:41 EST


There are some interesting things one could do with a similar system at
the kernel level.

If we had a table of IP ranges in the kernel that specify critical
sections with the restart points defined then the kernel could consult
that when preempting kernel threads and set the IP to the
restart point if the IP happened to be in one of the ranges.

If we had something like that then per cpu atomic sections would become
much simpler (avoid the preempt accounting and other preempt overhead
there?) and the per cpu atomic instructions would also be easier to
generalize for various architectures. Solves a lot of issues introduced by
preempt logic.

I think this could lead to a further simplification of allocator
fastpaths. Gets rid of a lot of strange code. Look at the simplification
of the fastpath due to the ability to be able to guarantee that a section
of code is executed without preemption.

mm/slubc::slab_alloc_node()

redo:
do {
tid = this_cpu_read(s->cpu_slab->tid);
c = raw_cpu_ptr(s->cpu_slab);
} while (IS_ENABLED(CONFIG_PREEMPT) &&
unlikely(tid != READ_ONCE(c->tid)));
barrier();

object = c->freelist;
page = c->page;
if (unlikely(!object || !node_match(page, node))) {

... slow path...

} else {
void *next_object = get_freepointer_safe(s, object);

if (unlikely(!this_cpu_cmpxchg_double(
s->cpu_slab->freelist, s->cpu_slab->tid,
object, tid,
next_object, next_tid(tid)))) {

note_cmpxchg_failure("slab_alloc", s, tid);
goto redo;
}
}



-------------------------------------------------
Using the restart point system
-------------------------------------------------


start_critical_section:
restart_point:

c = this_cpu_ptr(s->cpu_slab);
object = c->freelist;
page = c->page;
if (!unlikely(!object || !node_match(page, node)) {

... slow path ...

} else {

void *next_object = get_freepointer_safe(s, object);

end_critical_section:
c->freelist = next_object;

}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/