Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Apr 2014 09:12:34 +0800
From:      araujobsdport@gmail.com
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        FreeBSD Filesystems <freebsd-fs@freebsd.org>, Alexander Motin <mav@freebsd.org>, Garrett Wollman <wollman@freebsd.org>
Subject:   Re: RFC: How to fix the NFS/iSCSI vs TSO problem
Message-ID:  <2A998A50-C692-4EAC-A01C-79D5230566E6@gmail.com>
In-Reply-To: <1519461744.3785300.1396312903037.JavaMail.root@uoguelph.ca>
References:  <1519461744.3785300.1396312903037.JavaMail.root@uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello Rick,

I have some production servers with lots of NFS users that I can make a test=
 too, but it will cost time and we can only verify regression, as I can't ma=
ke any benchmark there!

Let me check, how loaded is this server and I tell you later; if you want me=
 do more tests, I can do so.

Best Regards.

On 2014/4/1, at 8:41, Rick Macklem <rmacklem@uoguelph.ca> wrote:

> Jordan Hubbard wrote:
>>=20
>> On Mar 31, 2014, at 8:53 AM, Marcelo Araujo <araujobsdport@gmail.com>
>> wrote:
>>=20
>>> I understand your concern about add more one sysctl, however maybe
>>> we can
>>> do something like ZFS does, if it detect the system is AMD and have
>>> more
>>> than X of RAM it enables some options by default, or a kind of
>>> warning can
>>> be displayed show the new sysctl option.
>>>=20
>>> Of, course other people opinion will be very welcome.
>>=20
>> Why not simply enable (conditionally compile) it in only for the x64
>> architecture?   If you=E2=80=99re on a 64 bit Intel architecture machine,=

>> chances are pretty good you=E2=80=99re also running hardware of reasonabl=
e
>> recent vintage and aren=E2=80=99t significantly HW constrained.
> I'm actually typing this on a single core amd64 with 2Gbytes of RAM, so
> I think enabling it only for both 64bits and at least some # of Gbytes of
> RAM would be better. (I agree that most amd64s will be relatively big
> machines, but not all;-)
>=20
> My biggest problem is that I have no way of testing this on a fairly
> big amd64 server at this time and I'd be a lot more comfortable committing=

> a patch that has been tested this way. (I realize that Marcelo has been
> running it for his benchmarks and that's a good start, but it isn't the
> same as a heavily loaded server.)
>=20
> I notice that Alexander is on the cc list and I've added Garrett, since
> those are the two guys that have been doing a bunch of server testing
> (and my thanks go to them for this). Maybe they will have a chance to
> test this patch on a heavily loaded server?
>=20
> Since I do want to test/debug the if_hw_tsomaxseg patch I have, I plan
> on inquiring to see if I can use something like the netperf cluster
> for this testing (in a couple of weeks when I get home).
>=20
> rick
>=20
>> I think it=E2=80=99s also fair to say that if you=E2=80=99re providing NFS=
 or iSCSI
>> services on an i386 with 512M of memory or a similarly endowed ARM
>> or PPC system, performance is not your first and primary concern.
>> You=E2=80=99re simply happy that it works at all. ;-)
>>=20
>> - Jordan
>>=20
>>=20



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A998A50-C692-4EAC-A01C-79D5230566E6>