![]() | ||||||||||
Messages in this thread |
On Fri, 7 May 2004, Neil Brown wrote: > On Friday May 7, tennert@science-computing.de wrote: > > Hi Neil (and others), > > > > is there any reason why current 2.4 kernels do not allow for > > NFSSVC_MAXBLKSIZE to become as large as 32k? > > Yes. > At server thread creation, you need to be able to > kmalloc(NFSSVC_MAXBLKSIZE+1024) > (or close to that) once per thread. On most architectures this is a > high-order alloc_pages and can often fail. > Also, on every UDP write request, the server needs to 'kmalloc' a buffer > to hold the whole request (actually on every request that is > fragmented, but write is most common). On most architectures, this > kmalloc will again require allocative several contiguous pages, which > can fail. > > So this patch is only safe if you have a large-patch arch or only use > NFS over TCP. So isn't it unsafe either with the NFSSVC_MAXBLKSIZE set to the original 8k? Or is it just less unsafe, then? Anyway, I assure you the lockups occurred exactly when server-side NFSv3/TCP got into the vanilla kernel at 2.4.19, and the only significant difference I could see was this. I always used NFSv3/TCP before then, and had no problems whatsoever. After that, I had to switch to UDP. > > There was once a patch floating around which allowed a larger > NFSSVC_MAXBLKSIZE on architectures with large page sizes, but it never > got properly submitted I think. > > > > > > The problem is when I use NFSv3/TCP with a 2.4.25, say, on the server > > side, as well as on the client side, I am experiencing lockups when > > copying medium-sized or large files from the NFS fs to a local fs. > > There must be some other cause. Increasing the NFSSVC_MAXBLKSIZE is > just hiding a real problem I suspect. > If only the coincidence was not so clear. Best regards and thanks Oliver __ ________________________________________creating IT solutions Dr. Oliver Tennert science + computing ag phone +49(0)7071 9457-598 Hagellocher Weg 71-75 fax +49(0)7071 9457-411 D-72070 Tuebingen, Germany O.Tennert@science-computing.de www.science-computing.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | ||||||||||