lkml.org 
[lkml]   [1997]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kernel > 2.1.36 & nfs
Date
In article <m0wYe4f-0005FnC@lightning.swansea.linux.org.uk>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>The IP fragmentation code is fine. Its just waiting Linus or someone to
>fix the memory allocator to reallocate or discard pages in patterns that
>build page groups. The other alternative is to make vmalloc() type operations
>interrupt safe - but that is even harder.
>
>So its not network layer, its lower - and when the lower layer is fixed
>the networking will trundle happily along as will NFS

Hmm.. This is both true and false.

One problem for the kernel is that it doesn't do large memory
allocations very gracefully, and that is what Alan calls broken. In
some sense it is broken, but on the other hand it is also a documented
feature: not doing the large memory allocations allows us to do other
things better.

So yes, this _could_ be fixed by changing the memory allocation policy
of the kernel. And we may want to do that for other reasons.

However, it is equally correct to say that the current fragment handling
is broken too - it does an unnecessary packet re-assembly on receive.
This re-assembly simplifies some code, but it not only has a bad impact
on memory management, it also involves a "useless" copy operation.

So the best solution would be to have the ability to handle fragmented
UDP packets on receive without reassembling them - that would get better
NFS performance due to getting rid of the copy, and it would also result
in better network buffer allocation.

(We already do "fragment on-the-fly" when sending UDP packets, it's only
reciving that doesn't handle it very nicely. Receiving is the harder of
the two, though, so it's understandable).

Linus

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