On 9/21/21 1:50 PM, Luck, Tony wrote: >> Did we ever figure out how much space storing really big ranges in the >> xarray consumes? > No. Willy said the existing xarray code would be less than optimal with > this usage, but that things would be much better when he applied some > maple tree updates to the internals of xarray. > > If there is some easy way to measure the memory backing an xarray I'm > happy to get the data. Or if someone else can synthesize it ... the two > ranges on my system that are added to the xarray are: > > $ dmesg | grep -i sgx > [ 8.496844] sgx: EPC section 0x8000c00000-0x807f7fffff > [ 8.505118] sgx: EPC section 0x10000c00000-0x1007fffffff > > I.e. two ranges of a bit under 2GB each. > > But I don't think the overhead can be too hideous: > > $ grep MemFree /proc/meminfo > MemFree: 1048682016 kB > > I still have ~ 1TB free. Which is much greater that the 640 KB which should > be "enough for anybody" :-). There is a kmem_cache_create() for the xarray nodes. So, you should be able to see the difference in /proc/meminfo's "Slab" field. Maybe boot with init=/bin/sh to reduce the noise and look at meminfo both with and without SGX your patch applied, or just with the xarray bits commented out. I don't quite know how the data structures are munged, but xas_alloc() makes it look like 'struct xa_node' is allocated from radix_tree_node_cachep. If that's the case, you should also be able to see this in even more detail in: # grep radix /proc/slabinfo radix_tree_node 432305 482412 584 28 4 : tunables 0 0 0 : slabdata 17229 17229 0 again, on a system with and without your new code enabled.
