> > 4 min 43 againt 4 min 51 without it (-j 8) > > Ah, this number is with a separate server for the input files. It might be > more interesting to see if it made a difference with the files all hosted on > the same server. With the source on the same lustre mount : - 5min34 without patch, source and build on same dir - 5min32 with patch, source and build on same dir - 5min59 with patch, source and build on 2 lustre dir (on the same mount) /o\ I made it 3 times, same result For ref : - 4 min 43 with patch and source on other mount - 4 min 51 without patch and source on other mount > > > 7min 40 against 7 min 42 with -j 8 > > This should be "-j 4" to match the above numbers, it was, typo. > Hmm, I'd thought possibly allowing more of the output files to be cached on > the clients would reduce the compilation time, but that doesn't seem to be > the bottleneck either. > > Did you try pre-reading all of the input files on the clients to see if > eliminating the small-file reads was a source of improvement? do you have any idea for doing that ? (It's a kernel compile ;)
> > I will try directly on the mds (so on only one node) to compare. I did, on an unpatched module version, and so only on one node : - 10m03 on a remote node, on same dir -j 4 - 6m30 on the MDS, source and compile on same dir , -j 4 - 6m30 on the MDS, source and compile on same dir , -j 8 - 5min54 on the MDS, source and compile on different dir, -j 8 I will also try on some other software (with some big c++ file, so that the ratio compilation time/access time would be better). Maxence -- Maxence DUNNEWIND Contact : [email protected] Site : http://www.dunnewind.net 06 32 39 39 93 GPG : 18AE 61E4 D0B0 1C7C AAC9 E40D 4D39 68DB 0D2E B533
signature.asc
Description: Digital signature
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
