8:21 p.m.
On Fri, Sep 21, 2018 at 05:35:48AM -0400, William Allen Simpson wrote:
On 9/20/18 7:27 AM, Malahal Naineni wrote:
>On Wed, Sep 19, 2018 at 11:33 PM, William Allen Simpson
<william.allen.simpson(a)gmail.com <mailto:william.allen.simpson@gmail.com>>
wrote:
>>
>> Try V4.1. V4.0 is only best effort, but not performance. V3 we try
>> not to break entirely.
>>
>
>What makes you think that his problem is going to go away with NSFv4.1? I am pretty
sure that the same issues exists in all versions.
>
Olga suggested trying V4.1. (She had also asked for the mount
parameters.) So I passed it along. DanG told me the rest.
>That is the default read/write size with GPFS FSAL. Smaller values generally perform
poorer!
>
Now we know why GPFS needs 4K threads and 200GB RAM.
But the NFS protocol is telling you those sizes are too big. They'll
only work well after you increase the system and socket buffer sizes,
and feed the correctly sized data accordingly. Otherwise, you just
have a huge amount of bufferbloat.
Anyway, talked with Bruce about what knfsd is doing. He says that
they used to enforce sizing and reject piggy clients, but there
were too many badly behaved operators.
I'm not sure what "badly behaved operators" means.
--b.
> So they took the checks out.
> You are free to self-denial-of-service.
>
> The ideal is to have just enough data arrive just in time to the
> queue, on one CPU that is closest feed to the interface. That will
> give the best performance.
>
>
> >> Nope. The server needs to STARVE clients that aren't optimal.
That's
> >> also the philosophy in the kernel TCP and net stack. And pretty much
> >> every router and switch in the network path.
> >>
> >
> >Correct, but I don't see any bad client here. Unfortunatley, we are starving
good clients here as we were waiting in writev() with slow clients (I don't want to
call them bad clients though).
> >
> We've been doing Fair Queuing for 30+ years. I'm old; I remember when
> John proposed it. :)
>
> Whereas I learned about Weighted Fair Queuing from Fred Baker in the
> early '90s, when he was implementing it for ACC.
>
> I was part of the bufferbloat project, and one of the earliest testers of
> fq_codel. That's the best practice, the current state of the art.
>
> Look, I've mentioned that I was overridden on this code design. The
> evidence is in the list archives. You have shipping product. It
> needs to work in the field. So let's massage your patch a little,
> and get stuff working better.
>
> We can argue another day about the best design. Bake-a-thon is about
> ensuring things work!
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org