On Mon, Aug 1, 2011 at 3:42 PM, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > On Mon, 2011-08-01 at 14:54 +0100, Adrien Kunysz wrote: >> Dear linux-nfs, >> >> I have a box that has recently been victim of an OOM caused by >> nfs_idmap_new() attempting to allocate a large amount of contiguous >> memory. This problem has been reported previously here [0] and I >> understand the real fix is to use CONFIG_NFS_USE_NEW_IDMAPPER. However >> I was wondering whether using non contiguous memory instead would be a >> valid workaround, especially considering the new ID mapper is not >> enabled by default. I have actually written a patch to that effect as >> I don't see any specific reason why that struct would need to be in >> contiguous memory. >> >> So before I do anything stupid with that patch, >> a) is there any good reason to use kzalloc() instead of vzalloc() in >> nfs_idmap_new()? > > vmalloc memory is a limited resource too. It certainly is but from my understanding it is much less prone to run into problem when the memory is fragmented (which is my problem here). I don't have a problem with how much memory it uses but with the size of the contiguous allocation. >> b) would you consider a patch that would make the function use vzalloc()? > > Is there any reason why you can't use the new idmapper now that it has > been integrated into the upstream nfs-utils? There are so many > scalability issues with the old idmapper that I'd rather deprecate its > use as quickly as possible. I must admit I feel more comfortable applying a three lines patch to my production systems than rebuilding with the new code and upgrading nfs-utils to a version that was released about a month ago (I assume 1.2.4 is expected to work with CONFIG_NFS_USER_NEW_IDMAPPER, I haven't verified). I understand we all want to move to the new code ASAP but the old code is likely to remain in use for some time and most people are not going to switch overnight so I think it would be useful to have a small workaround for this particular problem at least until we just remove that code altogether. Thanks, Adrien -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
