Stephan,
>> Yes, but this is because VM system's targets & pressure calcs do not
>> take into account fragmentation of the underlying physical memory.
>> IE, in theory you could have half your memory free, but
>> not be able to allocate a single 8k block. Nothing would cause
>> cache, or InactiveDirty stuff to be written.
>
> Which is obviously not the right way to go. I guess we agree in that.
Well, I agree that this is not desirable. I am not sure whether
the right course is
(a) to avoid getting here,
(b) to do traditional page_launder() stuff, i.e. write stuff out,
and hope that fixes it
(c) to actively go defragment (Daniel P's prefered approach)
(d) some combination of the above.
>> You yourself proved this, by switching rsize,wsize to 1k and said
>> it all worked fine! (unless I misread your email).
>
> Sorry, misunderstanding: I did not touch rsize/wsize. What I do is to lower fs
> action by not letting knfsd walk through the subtrees of a mounted fs. This
> leads to less allocs/frees by the fs layer which tend to fail and let knfs fail
> afterwards.
OK, I'm getting confused.
I'm looking at stuff you sent like:
Aug 29 13:43:34 admin kernel: pid=1207; __alloc_pages(gfp=0x20, order=3, ...)
Aug 29 13:43:34 admin kernel: Call Trace: [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>] [<fdceb7d7>]
Aug 29 13:43:34 admin kernel: [<fdcec0f5>] [<fdcea589>] [ip_local_deliver_finish+0/368] [nf_hook_slow+272/404] [ip_rcv_finish+0/480] [ip_local_deliver+436/444]
Aug 29 13:43:34 admin kernel: [ip_local_deliver_finish+0/368] [ip_rcv_finish+0/480] [ip_rcv_finish+413/480] [ip_rcv_finish+0/480] [nf_hook_slow+272/404] [ip_rcv+870/944]
Aug 29 13:43:34 admin kernel: [ip_rcv_finish+0/480] [net_rx_action+362/628] [do_softirq+111/204] [do_IRQ+219/236] [ret_from_intr+0/7] [sys_ioctl+443/532]
Aug 29 13:43:34 admin kernel: [system_call+51/56]
Aug 29 13:43:34 admin kernel: __alloc_pages: 3-order allocation failed (gfp=0x20/0).
If you use rsize=1024,wsize=1024, (note you may have to force
this at the client end), you should not see, at least from NFS,
allocations at greater than order 0. So if the problem is /just/
fragmentation (rather than too little memory), it will magically
go away (i.e. be hidden). If it's not just fragmentation, you
will still see errors. This is not intended as a solution, but
as a diagnostic tool. [I mistakenly thought/dreamed you had
already done this].
Note there may still be other things trying to do >0 order
allocs, for instance bounce buffers, but I believe you have
applied useful patches for them already.
-- Alex Bligh - 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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:35 EST