All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	avi@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: lapic: Fix the misuse of likely() in find_highest_vector()
Date: Thu, 30 Aug 2012 13:10:33 +0300	[thread overview]
Message-ID: <20120830101033.GA19622@redhat.com> (raw)
In-Reply-To: <20120830185052.086cbb0f.yoshikawa.takuya@oss.ntt.co.jp>

On Thu, Aug 30, 2012 at 06:50:52PM +0900, Takuya Yoshikawa wrote:
> On Thu, 30 Aug 2012 09:37:02 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > After staring at your code for a while it does appear to
> > do the right thing, and looks cleaner than what
> > we have now. commit log could be clearer.
> > It should state something like:
> > 
> > 
> > Clean up code in find_highest_vector:
> >  - likely() is there for historical reasons, it is no longer
> >    clear it's optimizing for the correct branch,
> >    and find_highest_vector might not be worth optimizing at all
> >  - checking word[0] separately does not make sense:
> >    if (word[word_offset << 2]) would be clearer
> >  - since we test word[...] != 0 beforehand, we can use __fls
> >    instead of fls()
> >  - for loop iterating over an array is clearer than while
> 
> Yes, I'll update the patch.
> 
> > Since you are going for cleanups, maybe we could also add:
> > - get rid of ugly >> 5 << 2, switch to using REG_POS instead?
> 
> OK, I'll do these on top of this patch.

Tweaking these 5 lines for readability across multiple
patches is just not worth it.
As long as we do random cleanups of this function it's probably easier
to just do them all in one patch.

> > Something like the below pseudo code would do this I think?
> > 
> > #define APIC_VECTORS_PER_REG 32
> > 
> > 	int vec;
> > 	for (vec = MAX_APIC_VECTOR - APIC_VECTORS_PER_REG;
> > 	     vec -= APIC_VECTORS_PER_REG; vec >= 0) {
> > 		u32 *reg = bitmap + REG_POS(vec);
> 
> We want to introduce apic_read_register(bitmap, reg) instead.
> u32 reg = apic_read_register(bitmap, REG_POS(vec));

If Marcelo takes it, I don't mind :)

> > 		if (*reg)
> > 			return __fls(*reg) - 1 + vec;
> 
> Because it is not clear that this *reg is the same value
> tested before. 

Before - where? Looks like this is the only place where
*reg is used.

> > 	}
> > 	return -1
> > 
> > count_vectors similar:
> > 
> >         for (vec = 0; vec < MAX_APIC_VECTOR; vec += APIC_VECTORS_PER_REG) {
> > 		u32 *reg = bitmap + REG_POS(vec);
> 
> Same here.

Same question :)

> >                 count += hweight32(*reg);
> > 	}
> > 
> > hmm?
> 
> Looks very good!
> 
> Thanks,
> 	Takuya

  reply	other threads:[~2012-08-30 10:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-24  9:15 [PATCH] KVM: x86: lapic: Fix the misuse of likely() in find_highest_vector() Takuya Yoshikawa
2012-08-27 20:25 ` Marcelo Tosatti
2012-08-28  9:57   ` Takuya Yoshikawa
2012-08-29 19:10     ` Marcelo Tosatti
2012-08-29 22:51       ` Michael S. Tsirkin
2012-08-30  1:09         ` Takuya Yoshikawa
2012-08-30  6:37           ` Michael S. Tsirkin
2012-08-30  9:50             ` Takuya Yoshikawa
2012-08-30 10:10               ` Michael S. Tsirkin [this message]
2012-08-30 10:24                 ` Takuya Yoshikawa
2012-08-30 10:44                   ` Michael S. Tsirkin
2012-08-30 12:30                     ` [PATCH -v3] KVM: x86: lapic: Clean up find_highest_vector() and count_vectors() Takuya Yoshikawa
2012-08-30 13:21                       ` Michael S. Tsirkin
2012-08-30 16:09                         ` Takuya Yoshikawa
2012-08-30 16:49                           ` Michael S. Tsirkin
2012-09-05  8:30                             ` Takuya Yoshikawa
2012-09-05  9:26                               ` Michael S. Tsirkin
2012-09-05  9:40                                 ` Takuya Yoshikawa
2012-09-05  9:51                                   ` Michael S. Tsirkin
2012-09-05 10:30                                     ` [PATCH -v4] " Takuya Yoshikawa
2012-09-05 10:58                                       ` Michael S. Tsirkin
2012-09-12 16:39                                       ` Marcelo Tosatti

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=20120830101033.GA19622@redhat.com \
    --to=mst@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=yoshikawa.takuya@oss.ntt.co.jp \
    /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.