>> Followings are patches for removing bitmaps from buddy
>allocator, against 2.6.9-rc3.
>> I think this version is much clearer than ones I posted a month ago.
>...
>> If there is unclear point, please tell me.
>
>What was the purpose behind this, again? Sorry, has been too long since
>I last looked.
>
For one, it avoids the otherwise requisite resizing of the bitmaps
during memory hotplug operations...
matt
On Thu, 2004-10-07 at 08:03, Tolentino, Matthew E wrote:
> >> Followings are patches for removing bitmaps from buddy=20
> >allocator, against 2.6.9-rc3.
> >> I think this version is much clearer than ones I posted a month ago.
> >...
> >> If there is unclear point, please tell me.
> >
> >What was the purpose behind this, again? Sorry, has been too long since
> >I last looked.
>
> For one, it avoids the otherwise requisite resizing of the bitmaps=20
> during memory hotplug operations...
It also simplifies the nonlinear implementation. The whole reason we
had the lpfn (Linear) stuff was so that the bitmaps could represent a
sparse physical address space in a much more linear fashion. With no
bitmaps, this isn't an issue, and gets rid of a lot of code, and a
*huge* source of bugs where lpfns and pfns are confused for each other.
-- Dave
--Dave Hansen <[email protected]> wrote (on Thursday, October 07, 2004 08:39:38 -0700):
> On Thu, 2004-10-07 at 08:03, Tolentino, Matthew E wrote:
>> >> Followings are patches for removing bitmaps from buddy=20
>> > allocator, against 2.6.9-rc3.
>> >> I think this version is much clearer than ones I posted a month ago.
>> > ...
>> >> If there is unclear point, please tell me.
>> >
>> > What was the purpose behind this, again? Sorry, has been too long since
>> > I last looked.
>>
>> For one, it avoids the otherwise requisite resizing of the bitmaps=20
>> during memory hotplug operations...
>
> It also simplifies the nonlinear implementation. The whole reason we
> had the lpfn (Linear) stuff was so that the bitmaps could represent a
> sparse physical address space in a much more linear fashion. With no
> bitmaps, this isn't an issue, and gets rid of a lot of code, and a
> *huge* source of bugs where lpfns and pfns are confused for each other.
Makese sense on both counts. Would be nice to add the justification to
the changelog ;-)
M.
On Thu, 2004-10-07 at 08:57, Martin J. Bligh wrote:
> Makese sense on both counts. Would be nice to add the justification to
> the changelog ;-)
Would you mind running these through your normal set of tests on the
NUMAQ? The last time I ran them, I didn't see a performance impact
either way, and I'd be good to check again.
-- Dave
>> Makese sense on both counts. Would be nice to add the justification to
>> the changelog ;-)
>
> Would you mind running these through your normal set of tests on the
> NUMAQ? The last time I ran them, I didn't see a performance impact
> either way, and I'd be good to check again.
Makes no difference in performance that I can see.
M.
--Dave Hansen <[email protected]> wrote (on Thursday, October 07, 2004 09:10:19 -0700):
> On Thu, 2004-10-07 at 08:57, Martin J. Bligh wrote:
>> Makese sense on both counts. Would be nice to add the justification to
>> the changelog ;-)
>
> Would you mind running these through your normal set of tests on the
> NUMAQ? The last time I ran them, I didn't see a performance impact
> either way, and I'd be good to check again.
Will do. What they're doing looks like it might be expensive. will check.
M.
Martin J. Bligh wrote:
>>>>What was the purpose behind this, again? Sorry, has been too long since
>>>>I last looked.
>>On Thu, 2004-10-07 at 08:03, Tolentino, Matthew E wrote:
>>
>>For one, it avoids the otherwise requisite resizing of the bitmaps=20
>>during memory hotplug operations...
>>
>> Dave McCracken wrote:
>> The memory allocator bitmaps are the main remaining reason we need the
>> concept of linear memory. If we can get rid of them, it's one step closer
>> to managing memory as a set of sections.
>>--Dave Hansen <[email protected]> wrote (on Thursday, October 07, 2004 08:39:38 -0700)
>>It also simplifies the nonlinear implementation. The whole reason we
>>had the lpfn (Linear) stuff was so that the bitmaps could represent a
>>sparse physical address space in a much more linear fashion. With no
>>bitmaps, this isn't an issue, and gets rid of a lot of code, and a
>>*huge* source of bugs where lpfns and pfns are confused for each other.
>
>
> Makese sense on both counts. Would be nice to add the justification to
> the changelog ;-)
>
It seems all I should answer is already answered.
Thank you all.
I'll add the purpose to the changelog.
Kame <[email protected]>
> M.
>