>
> Currently, async page reads are implemented only for rsize >= PAGE_SIZE
> (which is at 4096 on the ix86 platform), and uses four nfsiod processes.
> If rsize is smaller than 4096, each readpage operation is broken up
> into synchronous read operations of rsize each, which means that for
> rsize == 1024 you do four READ RPC calls of 1K to the NFS server.
>
Don't forget to tell him that if he changes the rsize & wsize from the
default of 1024, to a larger number, like 4096 (the page cache works in
this), or 8192 (most commercal Unices use this), things go _much_ faster.
> : Compiling is a very I/O intensive task (all the
> : include files, the compiler, the .I .S .o files).
>
> Indeed. Read caching helps a bit here, but not much. It seems that
> compiling is particularly slow because gcc writes out data in very small
> chunks, and since writes are not cached, each write operation causes
> and RPC call to the server. Try to watch NFS with tcpdump when doing
> a compile...
>
I think there is some option that makes the compiler write out in bigger
blocks, it's either a gcc option, or a rebuild the libc, and define this I
can't rember which, but it was discussed on this list some time ago, so
perhaps you should look in an archive for it (Looking at ld's man page,
and info pages it's either quite obscure, or not part of ld ...).
> Olaf
> --
> Olaf Kirch | Sometimes I lie in bed at night, and I ask myself: ``Why?''
> okir@monad.swb.de | Then a voice comes to me and says: ``Why, what?''
> -- Charlie Brown
>
Bryn
--
PGP key pass phrase forgotten, \ Overload -- core meltdown sequence
again :( and I don't care ;) | initiated.
/ This space is intentionally left
| blank, apart from this text ;-)
\____________________________________