To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
I *think* I have the logic of this right... Anyway, I was annoyed by
having to do the bloody ugly casts to unsigned long long in
arch-specific code. As near as I can tell, we only want this selectable
in the case of PAE on x86, and some random PPC and MIPS embedded boards.
For everyone else, it should be whatever the value of 64BIT is.
And I can be happy and continue using unsigned long and going about my
merry business.
Signed-off-by: Kyle McMartin <[email protected]>
---
diff --git a/mm/Kconfig b/mm/Kconfig
index c070ec0..c25a838 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -172,6 +172,7 @@ config MIGRATION
config RESOURCES_64BIT
bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT && EXPERIMENTAL)
+ depends on (MIPS || PPC32 || X86_PAE) || 64BIT
default 64BIT
help
This option allows memory and IO resources to be 64 bit.
From: Kyle McMartin <[email protected]>
Date: Sun, 28 Oct 2007 16:15:49 -0400
> To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
>
> I *think* I have the logic of this right... Anyway, I was annoyed by
> having to do the bloody ugly casts to unsigned long long in
> arch-specific code. As near as I can tell, we only want this selectable
> in the case of PAE on x86, and some random PPC and MIPS embedded boards.
>
> For everyone else, it should be whatever the value of 64BIT is.
>
> And I can be happy and continue using unsigned long and going about my
> merry business.
>
> Signed-off-by: Kyle McMartin <[email protected]>
32-bit sparc has 36-bit physical addresses and thus needs
64-bit resources too
On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:
> To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
>
> I *think* I have the logic of this right... Anyway, I was annoyed by
> having to do the bloody ugly casts to unsigned long long in
> arch-specific code. As near as I can tell, we only want this selectable
> in the case of PAE on x86, and some random PPC and MIPS embedded boards.
May I suggest trying:
$ grep RESOURCES_64BIT=y arch/*/configs/* arch/*/defconfig
to locate those architectures which use this?
FYI, that grep says ARM, ia64, mips, parisc, powerpc, PPC, s390, sparc64,
and x86 use this feature.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Sun, Oct 28, 2007 at 06:09:49PM -0700, David Miller wrote:
> From: Kyle McMartin <[email protected]>
> Date: Sun, 28 Oct 2007 16:15:49 -0400
>
> > To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
> >
> > I *think* I have the logic of this right... Anyway, I was annoyed by
> > having to do the bloody ugly casts to unsigned long long in
> > arch-specific code. As near as I can tell, we only want this selectable
> > in the case of PAE on x86, and some random PPC and MIPS embedded boards.
> >
> > For everyone else, it should be whatever the value of 64BIT is.
> >
> > And I can be happy and continue using unsigned long and going about my
> > merry business.
> >
> > Signed-off-by: Kyle McMartin <[email protected]>
>
> 32-bit sparc has 36-bit physical addresses and thus needs
> 64-bit resources too
I didn't realize this, since it wasn't set in any of the configs, or
select-ed by any of the Kconfig. Will add this in the next go 'round.
Cheers,
Kyle
On Mon, Oct 29, 2007 at 08:10:10AM +0000, Russell King wrote:
> On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:
> > To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
> >
> > I *think* I have the logic of this right... Anyway, I was annoyed by
> > having to do the bloody ugly casts to unsigned long long in
> > arch-specific code. As near as I can tell, we only want this selectable
> > in the case of PAE on x86, and some random PPC and MIPS embedded boards.
>
> May I suggest trying:
>
> $ grep RESOURCES_64BIT=y arch/*/configs/* arch/*/defconfig
>
> to locate those architectures which use this?
>
> FYI, that grep says ARM, ia64, mips, parisc, powerpc, PPC, s390, sparc64,
> and x86 use this feature.
>
It would be nice if the people who actually needed it would have
select-ed it. That's how I built the list.
Most of the other examples you listed are obviously 64bit... there should be
more occurances, but I guess they've (alpha, for instance) not updated
their defconfig in a dogs age.
Anyway, sorry I didn't notice ARM. I'll add it to the list on the next
round.
Regards,
Kyle
(but seriously, this should be select-ed, not just set in a defconfig
somewhere...)
On Mon, Oct 29, 2007 at 11:21:52AM -0400, Kyle McMartin wrote:
> On Mon, Oct 29, 2007 at 08:10:10AM +0000, Russell King wrote:
> > May I suggest trying:
> >
> > $ grep RESOURCES_64BIT=y arch/*/configs/* arch/*/defconfig
> >
> > to locate those architectures which use this?
> >
> > FYI, that grep says ARM, ia64, mips, parisc, powerpc, PPC, s390, sparc64,
> > and x86 use this feature.
> >
>
> It would be nice if the people who actually needed it would have
> select-ed it. That's how I built the list.
>
> Most of the other examples you listed are obviously 64bit... there should be
> more occurances, but I guess they've (alpha, for instance) not updated
> their defconfig in a dogs age.
>
> Anyway, sorry I didn't notice ARM. I'll add it to the list on the next
> round.
>
> Regards,
> Kyle
> (but seriously, this should be select-ed, not just set in a defconfig
> somewhere...)
No. On ARM it depends on the configuration. It's not an architectural
thing. For example, someone might decide to stuff a PCI bus with 64 bit
addressing onto an ARM CPU. Anyone without that definitely does not want
64 bit resources.
Some ARM systems with PCI busses, the PCI is added via means of an
external chip. You can't predict whether any particular SoC will have
a PCI bus, or whether it'll be 32-bit or 64-bit.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:
> +++ b/mm/Kconfig
> @@ -172,6 +172,7 @@ config MIGRATION
>
> config RESOURCES_64BIT
> bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT && EXPERIMENTAL)
> + depends on (MIPS || PPC32 || X86_PAE) || 64BIT
On MIPS it would be a per platform thing. I'd prefer if RESOURCES_64BIT
was enabled through reverse dependencies and never visible as a user
option.
Ralf
On Oct 29, 2007, at 9:48 PM, Ralf Baechle wrote:
> On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:
>
>> +++ b/mm/Kconfig
>> @@ -172,6 +172,7 @@ config MIGRATION
>>
>> config RESOURCES_64BIT
>> bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT
>> && EXPERIMENTAL)
>> + depends on (MIPS || PPC32 || X86_PAE) || 64BIT
>
> On MIPS it would be a per platform thing. I'd prefer if
> RESOURCES_64BIT
> was enabled through reverse dependencies and never visible as a user
> option.
The same is true on PPC32. Its a per platform thing. However, I'm
not sure if we could hide it from the user. There are cases on the
same HW platform that you want to run with just 32-bit phys (for
performance).
- k
On Mon, Oct 29, 2007 at 10:03:16PM -0500, Kumar Gala wrote:
> The same is true on PPC32. Its a per platform thing. However, I'm
> not sure if we could hide it from the user. There are cases on the
> same HW platform that you want to run with just 32-bit phys (for
> performance).
Have you measured what the performance difference is?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Tue, Oct 30, 2007 at 02:37:19AM -0600, Matthew Wilcox wrote:
> On Mon, Oct 29, 2007 at 10:03:16PM -0500, Kumar Gala wrote:
> > The same is true on PPC32. Its a per platform thing. However, I'm
> > not sure if we could hide it from the user. There are cases on the
> > same HW platform that you want to run with just 32-bit phys (for
> > performance).
>
> Have you measured what the performance difference is?
Two identical kernel configs, one with one without CONFIG_RESOURCES_64BIT:
text data bss dec hex filename
3334684 152208 138624 3625516 37522c vmlinux
3340352 152464 138752 3631568 3769d0 vmlinux
So that's 5668, 256 bytes data and 128 bytes of bss for a total of 6052
bytes. Not a whole lot but I still fear some users on the most
claustrophobic systems will mind.
Ralf
On Tue, Oct 30, 2007 at 11:42:21AM +0000, Ralf Baechle wrote:
> On Tue, Oct 30, 2007 at 02:37:19AM -0600, Matthew Wilcox wrote:
> > On Mon, Oct 29, 2007 at 10:03:16PM -0500, Kumar Gala wrote:
> > > same HW platform that you want to run with just 32-bit phys (for
> > > performance).
> >
> > Have you measured what the performance difference is?
>
> So that's 5668, 256 bytes data and 128 bytes of bss for a total of 6052
> bytes. Not a whole lot but I still fear some users on the most
> claustrophobic systems will mind.
Oh, sure, I'm not saying I thought there would be no size difference; I
was just bemused at the suggestion there was a performance difference.
Unless "won't fit in ROM any more" is considered a performance problem ;-)
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Tue, Oct 30, 2007 at 06:13:16AM -0600, Matthew Wilcox wrote:
> > On Tue, Oct 30, 2007 at 02:37:19AM -0600, Matthew Wilcox wrote:
> > > On Mon, Oct 29, 2007 at 10:03:16PM -0500, Kumar Gala wrote:
> > > > same HW platform that you want to run with just 32-bit phys (for
> > > > performance).
> > >
> > > Have you measured what the performance difference is?
> >
> > So that's 5668, 256 bytes data and 128 bytes of bss for a total of 6052
> > bytes. Not a whole lot but I still fear some users on the most
> > claustrophobic systems will mind.
>
> Oh, sure, I'm not saying I thought there would be no size difference; I
> was just bemused at the suggestion there was a performance difference.
>
> Unless "won't fit in ROM any more" is considered a performance problem ;-)
Linux has traditionally had a paranoid fear of 64-bit datatypes just
because GCC doesn't generate terribly efficient code for i386. I think
that may be the primary reason why CONFIG_RESOURCES_64BIT ever became a
build option. I doubt resource_size_t is being used in any critical
path so the bloat factor will matter much more than the performance
difference it makes. Unless you're terribly impatient waiting for your
PCI bus to complete scan or so ;-)
Ralf
On Oct 30, 2007, at 3:37 AM, Matthew Wilcox wrote:
> On Mon, Oct 29, 2007 at 10:03:16PM -0500, Kumar Gala wrote:
>> The same is true on PPC32. Its a per platform thing. However, I'm
>> not sure if we could hide it from the user. There are cases on the
>> same HW platform that you want to run with just 32-bit phys (for
>> performance).
>
> Have you measured what the performance difference is?
I have not. On some PPC32 systems having proper 36-bit physical
support usually means growing our pte to be 64-bits which creates
additional overhead in SW TLB mgmt on these processors.
- k
On Tue, Oct 30, 2007 at 06:13:16AM -0600, Matthew Wilcox wrote:
> On Tue, Oct 30, 2007 at 11:42:21AM +0000, Ralf Baechle wrote:
> > On Tue, Oct 30, 2007 at 02:37:19AM -0600, Matthew Wilcox wrote:
> > > On Mon, Oct 29, 2007 at 10:03:16PM -0500, Kumar Gala wrote:
> > > > same HW platform that you want to run with just 32-bit phys (for
> > > > performance).
> > >
> > > Have you measured what the performance difference is?
> >
> > So that's 5668, 256 bytes data and 128 bytes of bss for a total of 6052
> > bytes. Not a whole lot but I still fear some users on the most
> > claustrophobic systems will mind.
>
> Oh, sure, I'm not saying I thought there would be no size difference; I
> was just bemused at the suggestion there was a performance difference.
>
> Unless "won't fit in ROM any more" is considered a performance problem ;-)
I think we've gone way past that that issue NetWinders long ago... in the
2.4 days iirc.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: