2009-01-08 08:26:07

by Greg Banks

[permalink] [raw]
Subject: [patch 00/14] sunrpc: Sunrpc cache cleanups and upcall rework

G'day,

These patches are a snapshot of in-progress work to fix problems with
the sunrpc upcall mechanism which are triggered under load when using
multi-threaded rpc.mountd. These are currently a hot issue with one
of SGI's customers (SGI PV988959).

The early patches in the series are cleanups with zero logic changes.

The patches have been lightly tested, by mounting and running the
cthon04 tests. They have not been shipped or used in the field.

--
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.


2009-01-08 19:52:11

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [patch 00/14] sunrpc: Sunrpc cache cleanups and upcall rework

On Thu, Jan 08, 2009 at 07:25:10PM +1100, Greg Banks wrote:
> These patches are a snapshot of in-progress work

That sounds suspiciously like "do not apply!". I may as well queue up
the first 6 for 2.6.30, though?

> to fix problems with
> the sunrpc upcall mechanism which are triggered under load when using
> multi-threaded rpc.mountd. These are currently a hot issue with one
> of SGI's customers (SGI PV988959).
>
> The early patches in the series are cleanups with zero logic changes.
>
> The patches have been lightly tested, by mounting and running the
> cthon04 tests. They have not been shipped or used in the field.

OK, thanks.

--b.

2009-01-09 01:50:19

by Greg Banks

[permalink] [raw]
Subject: Re: [patch 00/14] sunrpc: Sunrpc cache cleanups and upcall rework

J. Bruce Fields wrote:
> On Thu, Jan 08, 2009 at 07:25:10PM +1100, Greg Banks wrote:
>
>> These patches are a snapshot of in-progress work
>>
>
> That sounds suspiciously like "do not apply!".
On these patches, it's your call.

When I say "in-progress" I really mean that these haven't shipped in an
SGI product. There are more patches in this same series, not yet posted,
which are definitely in the "do not apply" category and which I will
mark as such when they appear.

For the latter (logic-changing) patches, I can report that they've had
the same amount of testing that most Linux patches claim to have
received. In other words they worked fine on one architecture, with the
obvious publicly available testsuite, with a small client count, with
light load levels, and no data corruption testing, and no point
regression test for the bug being fixed. I've seen code checked into
Linux with less testing.

OTOH these patches have not been through an SGI QA cycle, and given the
circumstances it seems unlikely they will. So I would not ship these in
an SGI product yet.

Your call. I would be comfortable with these patches going into 2.6.30.

> I may as well queue up
> the first 6 for 2.6.30, though?
>
Yes, the first 6 make no logic changes and I believe they are quite
harmless.

--
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.