Messages in this thread | | | Subject | Re: 2.1.76, nfs client, and memory fragmentation | Date | Thu, 1 Jan 1998 02:22:27 -0600 (CST) | From | kwrohrer@enteract ... |
| |
And lo, Linus Torvalds saith unto me: > In article <199712291047.EAA28278@jadrek.kwr>, <kwrohrer@enteract.com> wrote: > >I'll try it, but I don't think this will solve the fragmentation. It will > >adjust the reservation to try to hold on to free chunks of larger orders, > >but once a high-priority allocation snags the last one we're back where we > >started, with no way of bringing high-order free chunks back into the > >system. [...] > Anyway, I'd like to know what people think about the patch (even just > subjective "feels less snappy" or similar) Having tried it with netscape (which didn't see ~/.netscape/bookmarks.html due to NFS timeouts and therefore overwrote it) in the mix, I conclude that it's a little better at resisting the no-big-chunks-free problem but once it happens, it still happens hard until something can be coerced into freeing lots of memory. I had 512k free, all in 4k and 8k hunks (according to fnord-ScrollLock) during the "brainstorm"; now I have 3 32kb and 65 16kb hunks free, but nothing larger.
Furthermore, I note even after *lots* of: jadrek kernel: IP: queue_glue: no memory for gluing queue c1adcc60
I see only:
jadrek kernel: Networking buffers in use : 40 jadrek kernel: Total network buffer allocations : 1600654 jadrek kernel: Total failed network buffer allocs : 1744 jadrek kernel: IP fragment buffer size : 0
The total allocations is reasonable, but the total failed seems awfully small, and the current fragment buffer size is disappointing. I did a ls -R on an NFS-mounted subdirectory, and the network buffers went down to 35, still no fragment buffer, despite rsize=4096 and wsize=4096 in /etc/fstab (though not reported by /proc/mounts). Even doing ping -s 8192 (in either direction across the link) still gives a fragment buffer size of 0 according to shift-ScrollLock! Something's rotten in Denmark.
But to get away from the networking side of things, unless (as I just posted) there's a reverse page table (or equivalent) I'm not seeing, there's not much intelligent I can do about the problem that wouldn't just re-write the swap-until-high-order-chunks-become-free patch that's already been written...
Keith
| |