On 08/22/2011 21:36, Matthew Dillon wrote:
The limitation was ONLY due to a *minor* 32-bit integer overflow in one or two *intermediate* calculations in the radix tree code, which I long ago fixed in DragonFly.Just find the changes in the DFly codebase and determine if they need to be applied. The swap space radix code (which I wrote long ago) is in page-sized blocks, so you actually probably want to keep using a 32-bit integer for the block number there to keep the physical memory reservation required for the radix tree low. If you just pop the base block id up to 64 bits without adjusting the radix code to overlay a 64 bit bitmap on it you waste a lot of physical memory for the same amount of swap reservation.
Unfortunately, in FreeBSD, when daddr_t was increased to 64 bits a few years ago, the bitmap size was not increased. So, we have been wasting about half the space used by the blist structure for some time now. I expect that we'll fix this after the current code freeze ends.
However, as Alexander observed, the primary reason for the 32GB limit on the size of a swap partition was artificial. The limit was being implemented in the wrong place. It was being performed before the conversion from 512 byte blocks to 4KB pages. Since a blist is managing swap space at the granularity of pages and the limit is imposed by the blist code, the check should come after the conversion. Just by moving the check to its proper place, the effective limit can be increased from 32GB to 256GB. Kostik committed such a change earlier today.
Alan _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
