On Wed, Oct 16, 2013 at 10:34:24PM +0100, Saso Kiselkov wrote: > On 10/16/13 8:57 PM, Prakash Surya wrote: > > Well, we're just increasing the size of the hash. So, given enough RAM, > > the problem of having enough buffers in the cache to cause large chains > > still exists. Right? Although, "enough RAM" might not be practically > > achievable. > > It would only be a problem if our relative resource usage changed > depending on the amount of the resource being present, i.e. if we used > 0.1% of physmem at 1GB but 1% at 1TB and 10% at 1PB - that is a problem > that's getting out of hand and doesn't scale. But in this case, the > relative proportions *don't* change. It's still going to be 0.1%, > regardless of the actual amount of physical memory present.
Yes, you're right. I realized my mistake shortly after sending that reply. > > > 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. > > > > Please do, I'd be very happy to simplify the code. OK, so as far as Linux is concerned, I don't think there is much need to worry ourselves with VM fragmentation. On 64-bit systems, the total vmalloc address space is *huge*. So we _should_ always be able to find a contiguous region to fit the allocation. Also, we're already making a pretty large single vmalloc with the current code, so I doubt this will make things much worse (if at all). If we're *really* worried about this issue, we should probably try to move away from needing a contiguous buffer altogether and use something like a scatter-gather implementation. But I'll save that for another day. On 32-bit systems, as Richard said, we only have 100MB of available vmalloc address space. Also, the Linux kernel is limited to 1G of RAM. So even if we were to use *all* of that space for the arc hash table, that'd only be a 1M allocation. So I don't think we really need to worry about that case, do we? I vote to keep the code simple and maintain the table as a 1D array. -- Cheers, Prakash > > Cheers, > -- > Saso _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
