lkml.org 
[lkml]   [1998]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.1.76, nfs client, and memory fragmentation
Date
From
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




\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.068 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site