Re: [Cvs-test-results] CVS trunk testing results (BSDI BSD/OS)

[Larry Jones]

Derek Price writes:
> 
> Okay, I'm not against this in principle, but before I make the change,
> I'm going to wrap my nightly tests with a call to "time" so we can spot
> any major slowdowns.  It may be a few days.

I was thinking along the same lines, but most of the nightly tests don't
deal with large files, so I'm not sure that's a valid test.  It might be
better to time just the compression test that does use a large file
rather than the entire suite.

> the client does appear to behave as you say.  send_modified should
> probably use buf_read_file too - this would fix half the problem.

Yes, I seem to remember a bug report where one system objected to the
ridiculously big read send_modified tries to do.  But buf_read_file()
may require some changes -- it looks like buf_read_file expects the
exact file size as an input and the client doesn't necessarily know the
exact size, only an upper bound.

> Do you know if mmap on any systems actually use the mapped file as the
> swap file for mapped memory?  If so, then having buf_read_file mmap a
> file rather than copying it into buffer_datas might allow the file to be
> read piecemeal just as it is written, and nothing would be copied to
> disk when portions of the buffer_data created this way were "swapped
> out".  i.e. a file might not ever be held in memory all at once, without
> any complex tracking on our part.

That would only work for binary files -- for text files, we need stdio
to do line ending conversions.

-Larry Jones

I think if Santa is going to judge my behavior over the last year,
I ought to be entitled to legal representation. -- Calvin