RE: [Lhms-devel] Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

RE: [Lhms-devel] Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Tolentino, Matthew E]

>> 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Dave Hansen]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Martin J. Bligh]

--Dave Hansen <haveblue@us.ibm.com> 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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Dave Hansen]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Martin J. Bligh]

--Dave Hansen <haveblue@us.ibm.com> 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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Martin J. Bligh]

>> 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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Hiroyuki KAMEZAWA]

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 <haveblue@us.ibm.com> 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 <kamezawa.hiroyu@jp.fujitsu.com>

> M.
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [Lhms-devel] Re: [PATCH] no buddy bitmap patch : intro and includes [0/2]

[Dave McCracken]

--On Thursday, October 07, 2004 07:45:21 -0700 "Martin J. Bligh"
<mbligh@aracnet.com> wrote:

>> 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.

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 McCracken

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>