Date: Wed, 13 Mar 2013 21:20:28 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@freebsd.org> Cc: Rick Macklem <rmacklem@freebsd.org>, fs@freebsd.org Subject: Re: Deadlock in the NFS client Message-ID: <1040319431.3883577.1363224028494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201303131356.37919.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I wrote:
> Does having a large # of nfsiod threads cause any serious problem for most
> systems these days?
>
> I'd be tempted to recode nfs_asyncio() as above and then, instead of nfs_iodmin
> and nfs_iodmax, I'd simply have:
> - a fixed number of nfsiod threads (this could be a tunable, with the
> understanding that it should be large for good performance)
I'm probably getting ahead of myself here, since changing nfs_asyncio() may/may not
fix the deadlock, but I thought I'd comment further on the above.
It may be possible to add a new nfs_iod_target (the desired # of nfsiod threads)
and adjust that dynamically based on the ratio of the # of times nfs_asyncio() returns:
#EIO/#0 --> when there are too many EIO returns, increase nfs_iod_target
--> very few EIO returns, decrease nfs_iod_target
- Use nfs_iodmin, nfs_iodmax as the limits for nfs_iod_target and set
nfs_iodmax much larger than it currently is, by default, with
nfs_iod_target set to what nfs_iodmax is currently set to, by default.
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1040319431.3883577.1363224028494.JavaMail.root>