[openib-general] Re: Re: [PATCH] (fixed) reduce qp locking on cq poll
Michael S. Tsirkin
mst at mellanox.co.il
Wed Jan 26 12:13:22 PST 2005
Quoting r. Grant Grundler <iod00d at hp.com>:
> Subject: Re: Re: [PATCH] (fixed) reduce qp locking on cq poll
>
> On Wed, Jan 26, 2005 at 09:37:49PM +0200, Michael S. Tsirkin wrote:
> > Quoting r. Grant Grundler <iod00d at hp.com>:
> > > Subject: Re: Re: [PATCH] (fixed) reduce qp locking on cq poll
> > >
> > > On Wed, Jan 26, 2005 at 07:19:02PM +0200, Michael S. Tsirkin wrote:
> > > > > I'm a little worried that you see no improvement from this patch -- it
> > > > > doesn't seem like fast hardware should be required.
> > >
> > > I was wondering the same thing. Why is fast HW required?
> >
> > See below.
>
> Sorry - I didn't see the answer "below".
> Can you be more specific?
Its not the speed of hardware, my problem is the variations.
> > > Can you quantify what you mean by "wild variations" and "big wins"?
> >
> > Goes up or down up to 3% on a bad day. Anything less is noise for me.
>
> Ok - I expect repeatability to be < 1% and ideally < 0.1%.
> On a private LAN at least. :^)
>
> > > Have you tried pinning the test processes to a particular CPU
> > > with taskset?
> >
> > No. Why will this help?
>
> cacheline ping-ponging will be the same between test runs.
>
> Did you see the difference in IPoIB numbers that I posted
> earlier where I pegged the test processes to the same CPU
> taking interrupts or a different CPU?
>
> For netperf, this was especially important for the system
> running "netserver" process.
>
> grant
No - link?
--
I dont speak for Mellanox
More information about the general
mailing list