bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Derek Price
Subject: Re: [Cvs-test-results] CVS trunk testing results (BSDI BSD/OS)
Date: Fri, 04 Nov 2005 18:08:51 -0500
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Larry Jones wrote:

>Maybe in the sense that if it were worth doing, malloc() should do it. 
>So if malloc() doesn't do it, it's probably not worth doing.
>  
>

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 gather that some systems don't automatically
>>align large malloc requests, or this GNULIB module probably would not
>>exist.
>>    
>>
>
>According to the comments in the module, you're the author!  It would
>seem that it was written specifically for CVS as a replacement for
>valloc().
>  
>

I did recall that, though I did have help from the GNULIB folks.  There
are one or two people there who probably would have stopped me and told
me the module was unnecessary if they thought it was.  :)  I had also
thought that there had been some bug reports from others, meaning others
had found a use for it, but glancing at the log messages for
pagealign_alloc.c, it appears that only a general GNULIB standard
compliance change & a rewrite of the FSF address in the license notice
have been made since the original changes Bruno & I came up with.

>A much more effective optimization would be to enhance the buffer system
>so that you could simply hand-off the original (non-page aligned!) big
>buffer to it rather than having to copy all the data.
>  
>

Hrm.  What big buffers get copied?  On the server, it looks to me like
buf_read_file already reads data directly into buffer_datas.  Then those
are moved directly into the buffer which outputs to the network.  Ah,
the client does appear to behave as you say.  send_modified should
probably use buf_read_file too - this would fix half the problem.

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.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:derek@ximbiot.com>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]