From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751945AbcA0Adt (ORCPT ); Tue, 26 Jan 2016 19:33:49 -0500 Received: from mail-pf0-f180.google.com ([209.85.192.180]:35477 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751458AbcA0Adn (ORCPT ); Tue, 26 Jan 2016 19:33:43 -0500 Date: Wed, 27 Jan 2016 09:34:56 +0900 From: Sergey Senozhatsky To: Andrew Morton Cc: Sergey Senozhatsky , Minchan Kim , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [PATCH] zram: export the number of available comp streams Message-ID: <20160127003456.GA1612@swordfish> References: <1453809839-21705-1-git-send-email-sergey.senozhatsky@gmail.com> <20160126131332.562f0984818b9d07b6c2b21c@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160126131332.562f0984818b9d07b6c2b21c@linux-foundation.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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