On Fri, 29 Dec 2017, Matthew Wilcox wrote:
> Is this the right approach? I could imagine there being more ops in
> the future. I suspect we should bite the bullet now and do:
>
> struct kmem_cache_operations {
> void (*ctor)(void *);
> void *(*isolate)(struct kmem_cache *, void **objs, int nr);
> void (*migrate)(struct kmem_cache *, void **objs, int nr, int node,
> void *private);
> };
Well yes but that would mean converting the existing call sites.
> Not sure how best to convert the existing constructor users to this scheme.
> Perhaps cheat ...
One of the prior releases of slab defragmentation did this. We could do it
at some point. For now the approach avoids changing the API.
> > @@ -4969,6 +4987,20 @@ static ssize_t ops_show(struct kmem_cach
> >
> > if (s->ctor)
> > x += sprintf(buf + x, "ctor : %pS\n", s->ctor);
> > +
> > + if (s->isolate) {
> > + x += sprintf(buf + x, "isolate : ");
> > + x += sprint_symbol(buf + x,
> > + (unsigned long)s->isolate);
> > + x += sprintf(buf + x, "\n");
> > + }
>
> Here you could print the symbol of the ops vector instead of the function
> pointer ...
Well yes if we had it and thne we could avoid printing individual fields.
--
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>
