On Wed, Oct 16, 2013 at 04:01:16PM -0400, Richard Yao wrote: > 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. >
But how does 32-bit vs 64-bit change the problem with respect to VM fragmentation? Also, you're limited to 4G of RAM on a 32-bit system, right? So it kind of solves itself. -- Cheers, Prakash _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
