On Wed, Mar 12, 2014 at 02:04:50PM -0400, Gabriel L. Somlo wrote: > On Wed, Mar 12, 2014 at 02:24:54PM +0100, Gerd Hoffmann wrote: > > You should get identical results with both methods. It's just that the > > e820 method is more future proof, i.e. if the numa people add support > > for non-contignous memory some day we don't have to adapt the smbios > > code to handle it. > > So, assuming we're staying under 2T, a single T16 array is created > with handle 0x1000. > > T17 devices are created in increments of 16Gigs, and they all point > back at the T16 array via their Array Handle field. > > One T19 "array mapped address" is created for below-4g memory, and a > second one for above-4g. > > T20 is where the fun begins. Apparently (assuming over-4g ram), > two T20s are created to split the first t17 device's memory into > the below-4g portion and the above-4g portion. > > From then on, one T20 corresponds to one T17. So we get X+1 T20s for > each X T17s (with the first two T20s pointing at the first T17, > and T20(x+1) pointing at T17(x) for every x after the first). > > Any idea how I can best anticipate accomodating numa on top of this ? > > Presumably there will be additional e820 entries resulting in extra > T19s, but what will that do to the T17s and the T20s ? :)
Thinking in small increments here, sorry for the self-reply: Do you anticipate a new field in e820_entry, perhaps hinting at which CPU the memory belongs to ? Even now, assuming type==E820_RAM, I know you're putting in exactly one or two entries (below-4g and above-4g). But if I use e820 in smbios, am I OK assuming there will always be precisely one entry for which (start+lengh <= 4G) ? At least with the current arithmetic I'm working directly with [below|above]_4g, so there's no way to mistakenly assume the wrong thing, until we explicitly add in NUMA support :) Thanks, --G
