On Thu, Jul 10, 2014 at 4:19 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On Jul 10, 2014, at 4:17 PM, Adamson, Andy <William.Adamson@xxxxxxxxxx> wrote: > >> >> On Jul 10, 2014, at 4:08 PM, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: >> >>> On Thu, Jul 10, 2014 at 4:01 PM, Adamson, Andy >>> <William.Adamson@xxxxxxxxxx> wrote: >>>> Hi >>>> >>>> A customer of ours, running a 2.6.32-431.5.1.el6.x86_64 kernel NFS client, is hittng the "rpciod/1: page allocation failure. order:2, mode:0x20", but only with NFSv3 hard mounts (not soft mounts), and not with NFSv4 (same application, same client hardware). Has anyone hit this issue with RHEL6.5? Any ideas on why NFSv3 would trigger this error and not NFSv4? >>>> >>>> I see in Red Hat Bugzilla 767127 - swapper: page allocation failure. order:1, mode:0x20 (edit) that a similar issue was solved by setting vm.zone_reclaim_mode = 1 which used to be the default. Adjusting the vm.min_free_kbytes higher may also help. Any side effects or issues with these settings? >>>> >>>> Any info appreciated >>> >>> Where are we doing an order 2 allocation in the NFS/RPC code? Our aim >>> has always been to do nothing larger than an order 0 allocation. >> >> I don’t yet have the Call trace triggered by the allocation failure, but I think it’s in the tcp layer. I’ll confirm. > > If the underlying network doesn’t support ->sendpages(), the TCP layer > would have to allocate a large buffer and copy the RPC payload into > the buffer. > > IPoIB has this issue, for example. > That might explain an order 1 allocation, but should not explain an order 2 on ordinary 1500 MTU ethernet. Are they perhaps trying to use jumbo frames with this kind of non-scatter-gather compatible hardware? -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
