Re: [PATCH] zram: export the number of available comp streams

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (01/26/16 13:13), Andrew Morton wrote:
[..]
> > +`avail_streams' column shows the current number of available compression
> > +streams, which is not necessarily equal to the number of max compression
> > +streams. The number of max compression streams can be set too high and be
> > +unreachable (depending on the load and the usage pattern, of course).
> > +`avail_streams' let to find out the real 'level of concurrency' that
> > +a particular zram device saw and to calculate the real memory consumption
> > +by allocated compression streams, not the theoretical maximum value.
> >
> 
> "number of max compression streams" doesn't make a lot of sense.  It
> should be "max number of compression streams", yes"

Thank you! much better this way.

[..]
> > +static int zcomp_strm_multi_num_avail_streams(struct zcomp *comp)
> > +{
> > +	int avail;
> > +	struct zcomp_strm_multi *zs = comp->stream;
> > +
> > +	spin_lock(&zs->strm_lock);
> > +	avail = zs->avail_strm;
> > +	spin_unlock(&zs->strm_lock);
> > +
> > +	return avail;
> > +}
> 
> The spin_lock() doesn't do anything very useful here - we're simply
> reading an `int' and it could be omitted.  I guess it's OK for
> documentary reasons (and perhaps for the memory barrier).

yes, agree, that was exactly my thinking. it's fine to have it here
for barrier, but at the same it can be scratched and replaced with
a "yes, this is racy. don't send a patch. `avail_streams' is not so
important" comment.

let's hear from Minchan, if he hates it then I'll just send a v2.

	-ss