On 10/16/2013 03:57 PM, Prakash Surya wrote: > On Wed, Oct 16, 2013 at 06:40:12PM +0100, Saso Kiselkov wrote: >> On 10/16/13 6:27 PM, Prakash Surya wrote: >>> If the completely dynamic approach isn't tractable, why split the table >>> into a 2D array? Why not just increase the size of it, and keep it a 1D >>> array? >> >> The reason why I split it was to reduce a single allocation size. The >> point is that on bigmem machines (with 1TB+ of physical DRAM) these >> allocations can grow to ridiculous sizes (1GB+). If the virtual address >> space is sufficiently fragmented this can create trouble. So far, at >> least, this is my hypothesis. If it's invalid, I will happily revert the >> code back to a 1D table, but so far we haven't been able to get VM >> experts to comment on this. I have seen one edge case where the kernel, >> under memory pressure, failed to allocate a contiguous 128k buffer - >> whether the scenario applies generally, though, I'm not certain. Again, >> not a VM expert. > > I'm no VM expert either, but speaking from Linux's perspective, I don't > think virtual address space fragmentation is much of an issue. AFAIK, > whether you're doing a 1M vmalloc or 1G vmalloc, VM fragmentation > doesn't play much of an issue. The kernel will allocate non-contiguous > pages and then present them as a contiguous region, so you just need > enough free pages on the system to satisfy the request. > > I should try and prod behlendorf about this, since he has much more > experience on the subject than I do. >
It would only cost a problem on 32-bit. On 64-bit, we have more address space than we can possibly use right now.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
