All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Tejun Heo <tj@kernel.org>
Cc: linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Stephen Tweedie <sct@redhat.com>,
	Jeremy Eder <jeder@redhat.com>
Subject: Re: [PATCH 1/5][RFC][CFT] percpu fixes, part 1
Date: Thu, 6 Mar 2014 20:30:30 +0000	[thread overview]
Message-ID: <20140306203030.GA18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140306192026.GA14033@htj.dyndns.org>

On Thu, Mar 06, 2014 at 02:20:26PM -0500, Tejun Heo wrote:

> Can you please add why this change is necessary to the description?

OK, will do...

> Also, I think it'd be better to split addition of first_free hint to a
> separate patch.

OK, but I'm not sure how much does it simplify things, actually.
 
> > +		chunk->map[++i] = off += size;
> >  }
> 
> Do we need to pass @size in the above function?  Isn't that something
> which can be easily determined?  If @size is gonna stay, we'll need to
> update the function comment too.

It's folded into the caller in the next patch.

> > @@ -483,19 +483,27 @@ static int pcpu_alloc_area(struct pcpu_chunk *chunk, int size, int align)
> >  	int oslot = pcpu_chunk_slot(chunk);
> >  	int max_contig = 0;
> >  	int i, off;
> > +	int seen_free = 0;
> 
> bool

Umm...  Matter of taste, but OK, I'll do that.

> > @@ -570,34 +584,50 @@ static int pcpu_alloc_area(struct pcpu_chunk *chunk, int size, int align)
> >  static void pcpu_free_area(struct pcpu_chunk *chunk, int freeme)
> >  {
> >  	int oslot = pcpu_chunk_slot(chunk);
> > -	int i, off;
> > -
> > -	for (i = 0, off = 0; i < chunk->map_used; off += abs(chunk->map[i++]))
> > -		if (off == freeme)
> > -			break;
> > +	int off = 0;
> > +	unsigned i, j;
> > +	int to_free = 0;
> > +	int *p;
> > +
> > +	freeme |= 1;
> > +
> > +	i = 0;
> > +	j = chunk->map_used;
> > +	while (i != j) {
> > +		unsigned k = (i + j) / 2;
> > +		off = chunk->map[k];
> > +		if (off < freeme)
> > +			i = k + 1;
> > +		else if (off > freeme)
> > +			j = k;
> > +		else
> > +			i = j = k;
> > +	}
> >  	BUG_ON(off != freeme);
> > -	BUG_ON(chunk->map[i] > 0);
> 
> A comment explaining why ignoring the free bit during bin search is
> okay would be nice?

Huh?  We are not ignoring it - we are searching for exact value, including
the lower bit being set.  It might be worth adding a comment next to
"freeme |= 1;" before the loop, but that's it.  These two BUG_ON() fold
nicely - that's one of the reasons why I prefer to keep the offset of
area and is_free flag of the same area in one array element.  That's why
I prefer to have the first element of array to be <0,false> or <0,true>,
and add <total_size, true> as the sentry in the end.  Sure, we could
keep <offset of the next, is this one free> together instead, and make
that array one element shorter, but that way we get more complex logics,
including that search in freeing...

> > +	if (unlikely(align < 2))
> > +		align = 2;
> 
> Please add a comment explaining why the above min alignment is
> necessary.

Umm...  Will "we want the lowest bit of offset available for free/in_use
indicator" do?

  reply	other threads:[~2014-03-06 20:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05  3:47 [PATCHES][RFC][CFT] scalability fixes for shitloads of mounts Al Viro
2014-03-05  3:49 ` [PATCH 1/5][RFC][CFT] percpu fixes, part 1 Al Viro
2014-03-06 19:20   ` Tejun Heo
2014-03-06 20:30     ` Al Viro [this message]
2014-03-06 20:47       ` Tejun Heo
2014-03-07  2:52         ` Al Viro
2014-03-07 12:30           ` Tejun Heo
2014-03-14 18:45           ` Al Viro
2014-03-14 18:47             ` Tejun Heo
2014-03-14 18:53               ` Al Viro
2014-03-17 20:12                 ` [PATCH percpu/for-3.15] percpu: allocation size should be even Tejun Heo
2014-03-05  3:50 ` [PATCH 2/5][RFC][CFT] fold pcpu_split_block() into the only caller Al Viro
2014-03-06 19:21   ` Tejun Heo
2014-03-05  3:51 ` [PATCH 3/5][RFC][CFT] smarter propagate_mnt() Al Viro
2014-03-05  3:51 ` [PATCH 4/5][RFC][CFT] reduce m_start() cost Al Viro
2014-03-05  3:52 ` [PATCH 5/5][RFC][CFT] resizable namespace.c hashes Al Viro
2014-03-07 17:17   ` Andi Kleen
2014-03-07 18:38     ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140306203030.GA18016@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=jeder@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.