Re: [RFC 3/8] slub: Add isolate() and migrate() methods

[Christopher Lameter <cl@linux.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>