[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121004201609.GJ10245@1wt.eu>
Date: Thu, 4 Oct 2012 22:16:09 +0200
From: Willy Tarreau <w@....eu>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: Dan Williams <dan.j.williams@...el.com>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Stephan Baerwolf <stephan.baerwolf@...ilmenau.de>,
Marcelo Tosatti <mtosatti@...hat.com>,
Michael Ellerman <michael@...erman.id.au>,
Avi Kivity <avi@...hat.com>
Subject: Re: [ 022/180] ioat2: kill pending flag
Hi Ben,
I'm doing a grouped reply for your reports.
On Thu, Oct 04, 2012 at 03:47:37PM +0100, Ben Hutchings wrote:
> On Tue, 2012-10-02 at 00:52 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Dan Williams <dan.j.williams@...el.com>
> >
> > commit 281befa5592b0c5f9a3856b5666c62ac66d3d9ee upstream.
> >
> > The pending == 2 case no longer exists in the driver so, we can use
> > ioat2_ring_pending() outside the lock to determine if there might be any
> > descriptors in the ring that the hardware has not seen.
> [...]
>
> What bug does this fix?
Quoting Mike Galbraith :
"While testing tbench 40 throughput on a 40 core (+SMT) Intel SDV S3E37,
I found spin_lock_bh() consuming _90%_ of the box, driving throughput
straight through the floor. The commit below fixed it up.
This looks horrific enough to me to qualify for 2.6.32-longterm."
> Is ioat2_ring_pending() *really* safe to call without the ring_lock?
I'll let Dan respond on this, he's the original path author.
On Thu, Oct 04, 2012 at 06:15:34PM +0100, Ben Hutchings wrote:
> On Tue, Oct 02, 2012 at 12:52:37AM +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: =?latin1?q?Stephan=20B=E4rwolf?= <stephan.baerwolf@...ilmenau.de>
> >
> > commit 0769c5de24621141c953fbe1f943582d37cb4244 upstream
> [...]
>
> I'm not sure where this comes from - but probably from cherry-picking
> backporting in my local repo. The correct upstream commit hash is
> bdb42f5afebe208eae90406959383856ae2caf2b.
I did some mistakes when cherry-picking patches, I used cherry-pick -x
on some of them because my fingers type "-x" automatically here, but
some of my scripts are used to automatically write the commit line from
the cherry-pick line.
When I noticed the error, I reviewed all the affected patches and fixed
the few erroneous ones by hand, but it seems like 2 of them have slipped
through the cracks, or I failed a copy-paste during the fix.
I'll fix the commits, thanks for checking !
On Thu, Oct 04, 2012 at 06:35:13PM +0100, Ben Hutchings wrote:
> On Tue, Oct 02, 2012 at 12:52:42AM +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Avi Kivity <avi@...hat.com>
> >
> > commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream
> [...]
> > --- a/arch/ia64/kvm/kvm-ia64.c
> > +++ b/arch/ia64/kvm/kvm-ia64.c
> > @@ -1185,6 +1185,11 @@ out:
> >
> > #define PALE_RESET_ENTRY 0x80000000ffffffb0UL
> >
> > +bool kvm_vcpu_compatible(struct kvm_vcpu *vcpu)
> > +{
> > + return irqchip_in_kernel(vcpu->kcm) == (vcpu->arch.apic != NULL);
> > +}
> > +
> [...]
>
> Fails to build; fixed by commit 8281715b4109b5ee26032ff7b77c0d575c4150f7.
Queued now, thanks very much!
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists