On 10/16/2013 04:06 PM, Prakash Surya wrote: > 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. >
You are limited to a 100MB address space on 32-bit Linux and we currently do not do well there. Anyway, I am working on a solution and I don't think the use of a 1D hash table will be a problem for us.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
