x86: Remove dma32_reserve_bootmem

PATCH In review Yinghai Lu 2 participants 8 messages Mar 28, 2011 – Apr 12, 2011 x86

lore

Share & tools

lore

Yinghai Lu

author

2011-03-28 17:57 UTC #0 lore raw

PATCH 1/1 x86: Remove dma32_reserve_bootmem

That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.

Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.

So We could remove those not needed code now.

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/include/asm/pci.h |    2 -
 arch/x86/kernel/pci-dma.c  |   64 ---------------------------------------------
 arch/x86/kernel/setup.c    |    1
 3 files changed, 67 deletions(-)

arch/x86/include/asm/pci.h +0 -2

Index: linux-2.6/arch/x86/include/asm/pci.h
===================================================================
@@ -135,8 +135,6 @@ void default_teardown_msi_irqs(struct pc
 #include "pci_64.h"
 #endif
 
-void dma32_reserve_bootmem(void);
-
 /* implement the pci_ DMA API in terms of the generic device dma_ one */
 #include <asm-generic/pci-dma-compat.h>

arch/x86/kernel/pci-dma.c +0 ~~-64~~

74 lines not on this page · raw message

arch/x86/kernel/setup.c +0 -1

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
@@ -988,7 +988,6 @@ void __init setup_arch(char **cmdline_p)
 
 	initmem_init();
 	memblock_find_dma_reserve();
-	dma32_reserve_bootmem();
 
 #ifdef CONFIG_KVM_CLOCK
 	kvmclock_init();

Jesse Barnes

2011-04-12 16:12 UTC #1 lore raw

Quoted 10 lines · On Mon, 28 Mar 2011 10:56:53 -0700 Yinghai Lu <[email protected]> wrote:

That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.
Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.
So We could remove those not needed code now.
Signed-off-by Yinghai Lu <[email protected]>

Looks like a nice cleanup, can you re-send based on my linux-next branch?

Thanks,

Signature · 1 line

Jesse Barnes, Intel Open Source Technology Center

Yinghai Lu

author

2011-04-12 17:23 UTC #2 lore raw

PATCH 1/1 x86: Remove dma32_reserve_bootmem

That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.

Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.

So We could remove those not needed code now.

-v2: rebase on pci-next

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/include/asm/pci.h |    2 -
 arch/x86/kernel/pci-dma.c  |   64 ---------------------------------------------
 arch/x86/kernel/setup.c    |    1
 3 files changed, 67 deletions(-)

arch/x86/include/asm/pci.h +0 -2

Index: linux-2.6/arch/x86/include/asm/pci.h
===================================================================
@@ -135,8 +135,6 @@ void default_teardown_msi_irqs(struct pc
 #include "pci_64.h"
 #endif
 
-void dma32_reserve_bootmem(void);
-
 /* implement the pci_ DMA API in terms of the generic device dma_ one */
 #include <asm-generic/pci-dma-compat.h>

arch/x86/kernel/pci-dma.c +0 ~~-64~~

74 lines not on this page · raw message

arch/x86/kernel/setup.c +0 -1

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
@@ -966,7 +966,6 @@ void __init setup_arch(char **cmdline_p)
 
 	initmem_init();
 	memblock_find_dma_reserve();
-	dma32_reserve_bootmem();
 
 #ifdef CONFIG_KVM_CLOCK
 	kvmclock_init();

Jesse Barnes

2011-04-12 17:47 UTC #3 lore raw

Quoted 4 lines · On Tue, 12 Apr 2011 10:20:48 -0700 Yinghai Lu <[email protected]> wrote:

That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.

Quoted 8 lines

Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.
So We could remove those not needed code now.
-v2: rebase on pci-next
Signed-off-by Yinghai Lu <[email protected]>

Hm, still didn't apply cleanly, I guess the patch got corrupted. I fixed it up by hand and applied to linux-next though, thanks.

Signature · 1 line

Jesse Barnes, Intel Open Source Technology Center

Yinghai Lu

author

2011-04-12 17:55 UTC #4 lore raw

Quoted 11 lines · Jesse Barnes

Quoted 8 lines · On Tue, 12 Apr 2011 10:20:48 -0700 Yinghai Lu<[email protected]> wrote:
That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.
Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.
So We could remove those not needed code now.

Quoted 7 lines

Quoted 4 lines
-v2: rebase on pci-next
Signed-off-by Yinghai Lu<[email protected]>
Hm, still didn't apply cleanly, I guess the patch got corrupted. I fixed it up by hand and applied to linux-next though, thanks.

sorry for that. looks like recent thunderbird upgrade convert TAB to space..

Thanks

Yinghai Lu

Jesse Barnes

2011-04-12 17:58 UTC #5 lore raw

Quoted 14 lines · On Tue, 12 Apr 2011 10:54:14 -0700 Yinghai Lu <[email protected]> wrote:

Quoted 13 lines · Jesse Barnes
Quoted 10 lines · On Tue, 12 Apr 2011 10:20:48 -0700 Yinghai Lu<[email protected]> wrote:
That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.
Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.
So We could remove those not needed code now.
-v2: rebase on pci-next

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
Signed-off-by Yinghai Lu<[email protected]>
Hm, still didn't apply cleanly, I guess the patch got corrupted. I fixed it up by hand and applied to linux-next though, thanks.
sorry for that. looks like recent thunderbird upgrade convert TAB to space..

Thanks for checking. I wonder why every mailer (and some MTAs!) feel the need to molest message content so thoroughly...

Signature · 1 line

Jesse Barnes, Intel Open Source Technology Center

Yinghai Lu

author

2011-04-12 19:25 UTC #6 lore raw

Quoted 20 lines · Jesse Barnes

Quoted 17 lines · On Tue, 12 Apr 2011 10:54:14 -0700 Yinghai Lu <[email protected]> wrote:
Quoted 16 lines · Jesse Barnes
Quoted 12 lines · On Tue, 12 Apr 2011 10:20:48 -0700 Yinghai Lu<[email protected]> wrote:
That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.
Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.
So We could remove those not needed code now.
-v2: rebase on pci-next
Signed-off-by Yinghai Lu<[email protected]>

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Hm, still didn't apply cleanly, I guess the patch got corrupted. I fixed it up by hand and applied to linux-next though, thanks.
sorry for that. looks like recent thunderbird upgrade convert TAB to space..
Thanks for checking. I wonder why every mailer (and some MTAs!) feel the need to molest message content so thoroughly...

looks like patchwork and LKML have tab instead of spaces.

https://patchwork.kernel.org/patch/701342/

https://lkml.org/lkml/2011/4/12/358

also it is very interesting: in thunderbox inbox/send box, some mails are viewed with TAB as spaces.
but source does have TAB.

Yinghai

Yinghai Lu

author

2011-04-12 20:18 UTC #7 lore raw

Quoted 32 lines · Yinghai Lu

Quoted 20 lines · Jesse Barnes
Quoted 17 lines · On Tue, 12 Apr 2011 10:54:14 -0700 Yinghai Lu <[email protected]> wrote:
Quoted 16 lines · Jesse Barnes
Quoted 12 lines · On Tue, 12 Apr 2011 10:20:48 -0700 Yinghai Lu<[email protected]> wrote:
That is workaround for holding dma32 buf when early bootmem could use up those range on system that have lots of RAM.
Now x86 is using memblock, and even nobootmem wrapper do top-down allocation.
So We could remove those not needed code now.
-v2: rebase on pci-next
Signed-off-by Yinghai Lu<[email protected]>
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Hm, still didn't apply cleanly, I guess the patch got corrupted. I fixed it up by hand and applied to linux-next though, thanks.
sorry for that. looks like recent thunderbird upgrade convert TAB to space..
Thanks for checking. I wonder why every mailer (and some MTAs!) feel the need to molest message content so thoroughly...
looks like patchwork and LKML have tab instead of spaces.

Quoted 8 lines

https://patchwork.kernel.org/patch/701342/
https://lkml.org/lkml/2011/4/12/358
also it is very interesting: in thunderbox inbox/send box, some mails are viewed with TAB as spaces.
but source does have TAB.

while using thunderbird 3.1.8 to send patch, need to set

mailnews.send_plaintext_flowed

to false.

otherwise viewer could show TAB as spaces.

Yinghai