[Lustre-discuss] Optimize parallel commpilation on lustre

[Maxence Dunnewind]

> > 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 : maxence at dunnewind.net
Site : http://www.dunnewind.net
06 32 39 39 93
GPG : 18AE 61E4 D0B0 1C7C AAC9  E40D 4D39 68DB 0D2E B533
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20100629/33663e40/attachment.pgp>