<br><div class="gmail_quote">On Tue, Apr 29, 2008 at 12:30 PM, Nitin Gupta <<a href="mailto:nitingupta910@gmail.com">nitingupta910@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> We could probably eliminate the need for compcache.size by going direct from<br>
> _kbytes to num_pages, allowing ~4TB devices. Using only num_pages would<br>
> increase the max size of compcache to ~16TB and simplify the compcache code<br>
> somewhat. Unfortunately it seem hard to get at PAGE_SIZE from userspace.<br>
<br>
</div>There are lot more issues with increasing size to such huge values.<br>
For e.g. table[] is currently a simple array</blockquote><div><br>I was thinking that this should be converted to an array of void*. All extra information could be stored in the tlsf allocated chunk. However this won't do much good until we are able to page out to disk.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> which will eat all memory<br>
for such large<br>
compcache device sizes</blockquote><div><br>Not necessarily. Current AMD processors support 256 exabytes of
physical ram, (rather than the mere 1TB of early AMD64 processors). On
such machines these sizes could be feasible.<br></div></div><br>In any case there is an integer overflow that can cause the compcache module to become broken. I have attached a patch that will cap the compcache size to avoid integer overflow.<br clear="all">
<br>--<br><br>An confusing and perhaps amusing fact:<br>linux-headers-2.6.24-16/include/linux/reiserfs_fs.h<br>contains:<br><br>#define MAX_UL_INT 0xffffffff<br>#define MAX_INT 0x7ffffff<br>#define MAX_US_INT 0xffff<br>
<br>I don't know why reiserfs sets MAX_INT to 0x7ffffff. Is it meant to be portable to 28-bit architectures or what?<br><br>-- <br>John C. McCabe-Dansted<br>PhD Student<br>University of Western Australia