On 10/14/13 10:52 PM, Matthew Ahrens wrote: > Presumably it also helps pools with small blocks, even if they don't use > L2ARC at all.
Yes. > Oh right, we wrote that back when you could reasonably boot from UFS and > then load the zfs kernel module afterward, when you might not have much > free memory. We might want to keep something similar even if we reduce > the contiguous address space requirement. Or not -- maybe it's > reasonable to fail if there's < 0.1% free memory. > > [..snip..] > > 1. Because the code is nontrivial. I'm asking that you show an actual > problem that this solves. E.g. failure to allocate virtual address > space on Linux. The code isn't *that* complicated, so it's OK if the > problem it solves is a relatively minor one. We've even had 128k allocations fail us in relatively recent history: http://www.listbox.com/member/archive/182191/2013/05/sort/time_rev/page/1/entry/16:252/ So assuming a contiguous block of several hundred MB will be available later on might be too risky. > 2. Because testing will reveal if the changes actually fix the problem. > If it's possible to run out of address space, you'll have problems in > dbuf_init() too; it's allocating 0.2% of RAM. > > While we're at it, how about adding a tunable for sizing the > dbuf_hash_table too? Good idea, I'll look into that. I only found this in ARC because I bumped up against it. Cheers, -- Saso _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
