Kapish K wrote:
>
> Hello,
> I had sent in a note on nfs performance issues some time back,
> and Mark Hemment had been kind enough to point out to the
> zerocopy networking patch. Well, we tried with it, and it does
> seem to have some improvement, but it seems to have screwed up
> nfs p
Hello,
I had sent in a note on nfs performance issues some time back,
and Mark Hemment had been kind enough to point out to the
zerocopy networking patch. Well, we tried with it, and it does
seem to have some improvement, but it seems to have screwed up
nfs performance a bit, because we se
> Thanks for the inputs.. But, if we cannot move back to 2.2.19
> and need to stick with 2.4.0 for our own reasons concerning the
> work underway, would it be possible to give us a pointer us to
> the list of issues related to this problem in the vm, so that we
> may attempt to try and get s
Hello,
Thanks for the inputs.. But, if we cannot move back to 2.2.19
and need to stick with 2.4.0 for our own reasons concerning the
work underway, would it be possible to give us a pointer us to
the list of issues related to this problem in the vm, so that we
may attempt to try and get so
I believe David Miller's latest zero-copy patches might help here.
In his patch, the pull-up buffer is now allocated near the top of stack
(in the sunrpc code), so it can be a blocking allocation.
This doesn't fix the core VM problems, but does relieve the pressure
_slightly_ on the VM (I a
> We have been seeing some problems with running nfs benchmarks
> at very high loads and were wondering if somebody could show
> some pointers to where the problem lies.
> The system is a 2.4.0 kernel on a 6.2 Red at distribution ( so
Use 2.2.19. The 2.4 VM is currently too broken to
6 matches
Mail list logo
