On 19.11.21 14:45, Jan Beulich wrote: > On 19.11.2021 13:13, Oleksandr Andrushchenko wrote: >> On 19.11.21 14:05, Jan Beulich wrote: >>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote: >>>> From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> >>>> >>>> Instead of handling a single range set, that contains all the memory >>>> regions of all the BARs and ROM, have them per BAR. >>> Iirc Roger did indicate agreement with the spitting. May I nevertheless >>> ask that for posterity you say a word here about the overhead, to make >>> clear this was a conscious decision? >> Sure, but could you please help me with that sentence to please your >> eye? I mean that it was you seeing the overhead while I was not as >> to implement the similar functionality as range sets do I still think we'll >> duplicate range sets at the end of the day. > "Note that rangesets were chosen here despite there being only up to > <N> separate ranges in each set (typically just 1)." Albeit that's > then still lacking a justification for the choice. Ease of > implementation? I guess yes. I'll put:
"Note that rangesets were chosen here despite there being only up to <N> separate ranges in each set (typically just 1). But rangeset per BAR was chosen for the ease of implementation and existing code re-usability." > > As to overhead - did you compare sizeof(struct rangeset) + N * > sizeof(struct range) with just N * sizeof(unsigned long [2])? I was not thinking about data memory sizes in the first place, but new code introduced to handle that. And to be maintained. > > Jan > Thank you, Oleksandr
