Re: [PATCH 6/7] zsmalloc: fold zs_obj_write() into zs_store()

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (26/11/10 11:45), Sergey Senozhatsky wrote:
[..]
> > >  	spin_unlock(&class->lock);
> > > @@ -1332,8 +1324,14 @@ int zs_malloc(struct zs_pool *pool, struct zs_handle *handle, size_t size,
> > >  	if (!zspage)
> > >  		return -ENOMEM;
> > >  
> > > +	/*
> > > +	 * New zspage is not in class->fullness_list or movable yet, so we
> > > +	 * can allocate the object and copy data before taking class->lock.
> > > +	 */
> > > +	obj = obj_malloc(pool, zspage, handle);
> > > +	obj_write(class, zspage, obj, src, size);
> > > +
> > >  	spin_lock(&class->lock);
> > > -	obj_malloc(pool, zspage, handle);
> > 
> > Should moving obj_malloc() and obj_write() outside class->lock (and
> > skipping zspage_read_lock()) for new zspages be split into a separate
> > patch on top? AFAICT, it's a separate change from merging the
> > interfaces.
> 
> Let me take a look.

I like the idea.  At first it looked like we might have a tiny corner
case is when N tasks attempt to allocate in the same size class, that
has zero empty zspages, which now potentially can result in N fresh
zspages added to the size class, each having one object allocated.
But the reality is that master does that already, so nothing new.

Maybe something to look into separately.