Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

2G memory split

 

 

First page Previous page 1 2 3 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


be-news06 at lina

Jan 10, 2006, 9:48 AM

Post #26 of 51 (2281 views)
Permalink
Re: 2G memory split [In reply to]

Mark Lord <lkml [at] rtr> wrote:
> So, the patch would now look like this:

can we please state something what the 3G_OPT is suppsoed to do? Is this "optimzed for 1GB Real RAM"? Should this be something like "2.5G" instead?

> + config VMSPLIT_3G_OPT
> + bool "3G/1G user/kernel split (for full 1G low memory)"

> + default 0xC0000000
> + default 0xB0000000 if VMSPLIT_3G_OPT
> + default 0x78000000 if VMSPLIT_2G
> + default 0x40000000 if VMSPLIT_1G

Grusss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mbligh at mbligh

Jan 10, 2006, 10:14 AM

Post #27 of 51 (2283 views)
Permalink
Re: 2G memory split [In reply to]

Linus Torvalds wrote:
>
> On Tue, 10 Jan 2006, Jens Axboe wrote:
>
>>A newer version, trying to cater to the various comments in here.
>>Changes:
>
>
> Can we do one final cleanup? Do all the magic in _one_ place, namely the
> x86 Kconfig file.
>
> Also, I don't think the NOHIGHMEM dependency is necessarily correct. A
> 2G/2G split can be advantageous with a 16GB setup (you'll have more room
> for dentries etc), but you obviously want to have HIGHMEM for that..
>
> Do it something like this:
>
> choice
> depends on EXPERIMENTAL
> prompt "Memory split"
> default DEFAULT_3G
> help
> Select the wanted split between kernel and user memory.
> If the address range available to the kernel is less than the
> physical memory installed, the remaining memory will be available
> as "high memory". Accessing high memory is a little more costly
> than low memory, as it needs to be mapped into the kernel first.
> Note that selecting anything but the default 3G/1G split will make
> your kernel incompatible with binary only modules.
>
> config DEFAULT_3G
> bool "3G/1G user/kernel split"
> config DEFAULT_3G_OPT
> bool "3G/1G user/kernel split (for full 1G low memory)"
> config DEFAULT_2G
> bool "2G/2G user/kernel split"
> config DEFAULT_1G
> bool "1G/3G user/kernel split"
> endchoice
>
> config PAGE_OFFSET
> hex
> default 0xC0000000
> default 0xB0000000 if DEFAULT_3G_OPT
> default 0x78000000 if DEFAULT_2G
> default 0x40000000 if DEFAULT_1G
>
> and then asm-i386/page.h can just do
>
> #define __PAGE_OFFSET ((unsigned long)CONFIG_PAGE_OFFSET)
>
> and you're done.

The non-1GB-aligned ones need to be disbarred when PAE is on, I think.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


coywolf at gmail

Jan 10, 2006, 10:28 AM

Post #28 of 51 (2289 views)
Permalink
Re: 2G memory split [In reply to]

2006/1/10, Jens Axboe <axboe [at] suse>:
> On Tue, Jan 10 2006, Byron Stanoszek wrote:
> > On Tue, 10 Jan 2006, Jens Axboe wrote:
> >
> > >>yes, i made it totally configurable in 2.4 days: 1:3, 2/2 and 3:1 splits
> > >>were possible. It was a larger patch to enable all this across x86, but
> > >>the Kconfig portion was removed a bit later because people _frequently_
> > >>misconfigured their kernels and then complained about the results.
> > >
> > >How is this different than all other sorts of misconfigurations? As far
> > >as I can tell, the biggest "problem" for some is if they depend on some
> > >binary module that will of course break with a different page offset.
> > >
> > >For simplicity, I didn't add more than the 2/2 split, where we could add
> > >even a 3/1 kernel/user or a 0.5/3.5 (I think sles8 had this).
> >
> > I prefer setting __PAGE_OFFSET to (0x78000000) on machines with 2GB of RAM.
> > This seems to let the kernel use the full 2GB of memory, rather than just
> > 1920-1984 MB (at least back in 2.4 days).
>
> A newer version, trying to cater to the various comments in here.
> Changes:
>
> - Add 1G_OPT split, meant for 1GiB machines. Uses 0xB0000000
> - Add 1G/3G split
> - Move the 2G/2G a little, so the full 2GiB of ram can be mapped.
> - Improve help text (I hope :)
> - Make option depend on EXPERIMENTAL.
> - Make the page.h a lot more readable.
>
> ---
>
> Add option for configuring the page offset, to better optimize the
> kernel for higher memory machines. Enables users to get rid of high
> memory for eg a 1GiB machine.
>
> Signed-off-by: Jens Axboe <axboe [at] suse>
>
> diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
> index d849c68..fcad8f7 100644
> --- a/arch/i386/Kconfig
> +++ b/arch/i386/Kconfig
> @@ -444,6 +464,32 @@ config HIGHMEM64G
>
> endchoice
>
> +choice
> + depends on NOHIGHMEM && EXPERIMENTAL
> + prompt "Memory split"
> + default DEFAULT_3G
> + help
> + Select the wanted split between kernel and user memory.
> +
> + If the address range available to the kernel is less than the
> + physical memory installed, the remaining memory will be available
> + as "high memory". Accessing high memory is a little more costly
> + than low memory, as it needs to be mapped into the kernel first.
> +
> + Note that selecting anything but the default 3G/1G split will make
> + your kernel incompatible with binary only modules.
> +
> + config DEFAULT_3G
> + bool "3G/1G user/kernel split"
> + config DEFAULT_3G_OPT
> + bool "3G/1G user/kernel split (for full 1G low memory)"
> + config DEFAULT_2G
> + bool "2G/2G user/kernel split"
> + config DEFAULT_1G
> + bool "1G/3G user/kernel split"

I don't like these names. Can't your invent better ones?
Having multiple defaults seems odd. See these maybe:

MEMSPLIT_U3_K1
MEMSPLIT_U11_K5
MEMSPLIT_U39_K44
MEMSPLIT_U1_K3

odd too? midnight here. |-)

> +
> +endchoice
> +
> config HIGHMEM
> bool
> depends on HIGHMEM64G || HIGHMEM4G
> diff --git a/include/asm-i386/page.h b/include/asm-i386/page.h
> index 73296d9..7da50a1 100644
> --- a/include/asm-i386/page.h
> +++ b/include/asm-i386/page.h
> @@ -109,11 +109,23 @@ extern int page_is_ram(unsigned long pag
>
> #endif /* __ASSEMBLY__ */
>
> +#if defined(CONFIG_DEFAULT_3G)
> +#define __PAGE_OFFSET_RAW (0xC0000000)
> +#elif defined(CONFIG_DEFAULT_3G_OPT)
> +#define __PAGE_OFFSET_RAW (0xB0000000)
> +#elif defined(CONFIG_DEFAULT_2G)
> +#define __PAGE_OFFSET_RAW (0x78000000)
> +#elif defined(CONFIG_DEFAULT_1G)
> +#define __PAGE_OFFSET_RAW (0x40000000)
> +#else
> +#error "Bad user/kernel offset"
> +#endif
> +
> #ifdef __ASSEMBLY__
> -#define __PAGE_OFFSET (0xC0000000)
> +#define __PAGE_OFFSET __PAGE_OFFSET_RAW
> #define __PHYSICAL_START CONFIG_PHYSICAL_START
> #else
> -#define __PAGE_OFFSET (0xC0000000UL)
> +#define __PAGE_OFFSET ((unsigned long)__PAGE_OFFSET_RAW)
> #define __PHYSICAL_START ((unsigned long)CONFIG_PHYSICAL_START)
> #endif
> #define __KERNEL_START (__PAGE_OFFSET + __PHYSICAL_START)
>
> --
> Jens Axboe
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


--
Coywolf Qi Hunt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


coywolf at gmail

Jan 10, 2006, 10:33 AM

Post #29 of 51 (2285 views)
Permalink
Re: 2G memory split [In reply to]

2006/1/10, Linus Torvalds <torvalds [at] osdl>:
>
>
> On Tue, 10 Jan 2006, Mark Lord wrote:
> >
> > Are "DEFAULT_*" really the best names to assign to these options?
> > For these options, I'd expect something like "VMUSER_*" or "USERMEM_*".
>
> Good point. I just took the naming from the original one. Especially if
> all the logic is moved into Kconfig files, it has nothing to do with
> DEFAULT what-so-ever. More of a VMSPLIT_3G or similar..

Good. VMSPLIT_ is better than my MEMSPLIT_.

>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


--
Coywolf Qi Hunt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at osdl

Jan 10, 2006, 10:34 AM

Post #30 of 51 (2282 views)
Permalink
Re: 2G memory split [In reply to]

On Tue, 10 Jan 2006, Martin Bligh wrote:
>
> The non-1GB-aligned ones need to be disbarred when PAE is on, I think.

Well, right now _all_ the non-3:1 cases need to be disbarred. I think we
depend on the kernel mapping only ever being the _one_ last entry in the
top-level page table, which is only true with the 3:1 mapping.

But I didn't check.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mbligh at mbligh

Jan 10, 2006, 10:39 AM

Post #31 of 51 (2265 views)
Permalink
Re: 2G memory split [In reply to]

Linus Torvalds wrote:
>
> On Tue, 10 Jan 2006, Martin Bligh wrote:
>
>>The non-1GB-aligned ones need to be disbarred when PAE is on, I think.
>
>
> Well, right now _all_ the non-3:1 cases need to be disbarred. I think we
> depend on the kernel mapping only ever being the _one_ last entry in the
> top-level page table, which is only true with the 3:1 mapping.
>
> But I didn't check.

I think it was OK as of 2.6.5 or so, unless something changed recently.
Used to work unless you had PAE on, and a non-aligned split ... I had
that patch as a config option for a long time, as did SuSE, etc.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


lkml at rtr

Jan 10, 2006, 10:45 AM

Post #32 of 51 (2274 views)
Permalink
Re: 2G memory split [In reply to]

Jeff V. Merkey wrote:
> Linus Torvalds wrote:
>> On Tue, 10 Jan 2006, Martin Bligh wrote:
>>> The non-1GB-aligned ones need to be disbarred when PAE is on, I think.
>> Well, right now _all_ the non-3:1 cases need to be disbarred. I think
>> we depend on the kernel mapping only ever being the _one_ last entry
>> in the top-level page table, which is only true with the 3:1 mapping.
>>
>> But I didn't check.
..
>
> No. It works fine (or seems to) with 2:2 mapping. I've tested with these
> extensively
..

The boundary for 2:2 with the current patch is 0x78000000, not 0x80000000.
It may still work, but nobody's checked yet.

cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mbligh at mbligh

Jan 10, 2006, 10:46 AM

Post #33 of 51 (2283 views)
Permalink
Re: 2G memory split [In reply to]

> No. It works fine (or seems to) with 2:2 mapping. I've tested with these
> extensively
> and am shipping products on the 1U appliances with 2:2 and I have never
> seen any problems
> with 2.6.9-2.6.13.

Thanks, that helps.

> The only unpleasant side affect with 3:1 is user apps seem to rely on
> swap space
> a little more than I like -- perhaps this is the side affect you are
> referring to?
>
> RH ES uses 4:4 which is ideal and superior to this hack.

Ideal in that it's universally slower, and most people don't need it?
;-) 4:4 is a workaround for a very specialized, and rare situation.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


haveblue at us

Jan 10, 2006, 10:55 AM

Post #34 of 51 (2288 views)
Permalink
Re: 2G memory split [In reply to]

On Tue, 2006-01-10 at 10:34 -0800, Linus Torvalds wrote:
> On Tue, 10 Jan 2006, Martin Bligh wrote:
> >
> > The non-1GB-aligned ones need to be disbarred when PAE is on, I think.
>
> Well, right now _all_ the non-3:1 cases need to be disbarred. I think we
> depend on the kernel mapping only ever being the _one_ last entry in the
> top-level page table, which is only true with the 3:1 mapping.

It actually "just works". We have a 16GB machine that gets a lot of
filesystem activity and use a 2:2 split all the time. Appended patch is
all that we need.

It was for other reasons at the time, but I think we fixed a bunch of
the multiple kernel mapping PMDs back in 2.5. Some remnants of that
stuff are still around.

http://marc.theaimsgroup.com/?l=linux-kernel&m=104197008817507&w=2

diff -purN -X /home/dvhart/.diff.exclude /home/linux/views/linux-2.6.12/include/asm-i386/page.h 2.6.12-uptime/include/asm-i386/page.h
--- /home/linux/views/linux-2.6.12/include/asm-i386/page.h 2005-03-02 03:00:08.000000000 -0800
+++ 2.6.12-uptime/include/asm-i386/page.h 2005-07-27 11:53:40.000000000 -0700
@@ -122,9 +122,9 @@ extern int sysctl_legacy_va_layout;
#endif /* __ASSEMBLY__ */

#ifdef __ASSEMBLY__
-#define __PAGE_OFFSET (0xC0000000)
+#define __PAGE_OFFSET (0x80000000)
#else
-#define __PAGE_OFFSET (0xC0000000UL)
+#define __PAGE_OFFSET (0x80000000UL)
#endif

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mlord at pobox

Jan 10, 2006, 10:58 AM

Post #35 of 51 (2283 views)
Permalink
Re: 2G memory split [In reply to]

Mark Lord wrote:
..
> +choice
> + depends on EXPERIMENTAL && !X86_PAE
> + prompt "Memory split"
> + default VMSPLIT_3G
> + help
> + Select the desired split between kernel and user memory.
> +
> + If the address range available to the kernel is less than the
> + physical memory installed, the remaining memory will be available
> + as "high memory". Accessing high memory is a little more costly
> + than low memory, as it needs to be mapped into the kernel first.
> + Note that increasing the kernel address space limits the range
> + available to user programs, making the address space there
> + tighter. Selecting anything other than the default 3G/1G split
> + will also likely make your kernel incompatible with binary-only
> + kernel modules.
> +
> + If you are not absolutely sure what you are doing, leave this
> + option alone!
> +
> + config VMSPLIT_3G
> + bool "3G/1G user/kernel split"
> + config VMSPLIT_3G_OPT
> + bool "3G/1G user/kernel split (for full 1G low memory)"
> + config VMSPLIT_2G
> + bool "2G/2G user/kernel split"
> + config VMSPLIT_1G
> + bool "1G/3G user/kernel split"
> +endchoice
> +
> +config PAGE_OFFSET
> + hex
> + default 0xC0000000
> + default 0xB0000000 if VMSPLIT_3G_OPT
> + default 0x78000000 if VMSPLIT_2G
> + default 0x40000000 if VMSPLIT_1G
> +
...
> #ifdef __ASSEMBLY__
> -#define __PAGE_OFFSET (0xC0000000)
> +#define __PAGE_OFFSET CONFIG_PAGE_OFFSET
> #define __PHYSICAL_START CONFIG_PHYSICAL_START
> #else
> -#define __PAGE_OFFSET (0xC0000000UL)
> +#define __PAGE_OFFSET ((unsigned long)CONFIG_PAGE_OFFSET)
> #define __PHYSICAL_START ((unsigned long)CONFIG_PHYSICAL_START)
> #endif
> #define __KERNEL_START (__PAGE_OFFSET + __PHYSICAL_START)

Mmm.. somethings wrong with this version..
I have selected VMSPLIT_2G, but on rebooting the kernel
now only sees/uses 1GB of RAM (the machine has 2GB of RAM).

Almost as if those trailing "if VMSPLIT_" clauses are being ignored.
--
Mark Lord
Real-Time Remedies Inc.
mlord [at] pobox

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


axboe at suse

Jan 10, 2006, 10:58 AM

Post #36 of 51 (2263 views)
Permalink
Re: 2G memory split [In reply to]

On Tue, Jan 10 2006, Jeff V. Merkey wrote:
> RH ES uses 4:4 which is ideal and superior to this hack.

This isn't a hack, it's just making the offset configurable so you can
get the best of what you want.

And 4:4 may be ideal in a peyote haze, so whatever.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


lkml at rtr

Jan 10, 2006, 11:01 AM

Post #37 of 51 (2271 views)
Permalink
Re: 2G memory split [In reply to]

Dave Hansen wrote:
>
> It actually "just works". We have a 16GB machine that gets a lot of
> filesystem activity and use a 2:2 split all the time. Appended patch is
> all that we need.

Your (tested) patch is not the same as what is being proposed here,
so the testing experience probably doesn't apply.

The 2:2 boundary is different here.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


haveblue at us

Jan 10, 2006, 11:05 AM

Post #38 of 51 (2274 views)
Permalink
Re: 2G memory split [In reply to]

On Tue, 2006-01-10 at 14:01 -0500, Mark Lord wrote:
> Dave Hansen wrote:
> >
> > It actually "just works". We have a 16GB machine that gets a lot of
> > filesystem activity and use a 2:2 split all the time. Appended patch is
> > all that we need.
>
> Your (tested) patch is not the same as what is being proposed here,
> so the testing experience probably doesn't apply.
>
> The 2:2 boundary is different here.

That'll teach me not to read the patch. That actually makes the link I
sent more topical because it allowed the user:kernel split with PAE to
occur away from hard PMD boundaries.

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmerkey at wolfmountaingroup

Jan 10, 2006, 11:12 AM

Post #39 of 51 (2279 views)
Permalink
Re: 2G memory split [In reply to]

Alan Cox wrote:

>On Maw, 2006-01-10 at 09:56 -0700, Jeff V. Merkey wrote:
>
>
>>RH ES uses 4:4 which is ideal and superior to this hack.
>>
>>
>
>Its a non trivial trade-off. 4/4 lets you run very large physical memory
>systems much more efficiently than usual but you pay a cost on syscalls
>and some other events when using the majority of processors. The 4/4
>tricks also give most emulations (eg Qemu) serious heartburn trying to
>emulate %cr3 reloading via mmap and other interfaces with high overhead
>in relative terms.
>
>Of course AMD64 kind of shot the problem in the head once and for all.
>
>
>

Yep, they sure did. Seriously, the 4:4 option should also be present
along with 3:1 and 2:2
splits. You should merge your RH work into this patch and allow both.
It would save me one less
patch to maintain off the tree.

Alan, you're the man.

:-)

Jeff

>Alan
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmerkey at wolfmountaingroup

Jan 10, 2006, 11:30 AM

Post #40 of 51 (2281 views)
Permalink
Re: 2G memory split [In reply to]

Jens Axboe wrote:

>On Tue, Jan 10 2006, Jeff V. Merkey wrote:
>
>
>>Alan Cox wrote:
>>
>>
>>
>>>On Maw, 2006-01-10 at 09:56 -0700, Jeff V. Merkey wrote:
>>>
>>>
>>>
>>>
>>>>RH ES uses 4:4 which is ideal and superior to this hack.
>>>>
>>>>
>>>>
>>>>
>>>Its a non trivial trade-off. 4/4 lets you run very large physical memory
>>>systems much more efficiently than usual but you pay a cost on syscalls
>>>and some other events when using the majority of processors. The 4/4
>>>tricks also give most emulations (eg Qemu) serious heartburn trying to
>>>emulate %cr3 reloading via mmap and other interfaces with high overhead
>>>in relative terms.
>>>
>>>Of course AMD64 kind of shot the problem in the head once and for all.
>>>
>>>
>>>
>>>
>>>
>>Yep, they sure did. Seriously, the 4:4 option should also be present
>>along with 3:1 and 2:2
>>splits. You should merge your RH work into this patch and allow both.
>>It would save me one less
>>patch to maintain off the tree.
>>
>>
>
>You can't compare the two patches, saying that 4:4 should go in because
>configurable page offsets is merged is nonsense.
>
>Note that I'm not advocating against 4:4 as such, I have no real
>oppinion on that. It has its uses for sure, while it comes with a cost
>for others.
>
>
>
I agree and I appreciate your recognizing this. As it stands, if I need
4:4 I just ship on ES3 and ES4. the 3:1
patch in the standard kernel is a very good thing, and you are to be
commended for finally getting it in.

P.S. Your bio stuff works great.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


axboe at suse

Jan 10, 2006, 11:42 AM

Post #41 of 51 (2277 views)
Permalink
Re: 2G memory split [In reply to]

(please don't drop people from the cc list)

On Tue, Jan 10 2006, Bernd Eckenfels wrote:
> Mark Lord <lkml [at] rtr> wrote:
> > So, the patch would now look like this:
>
> can we please state something what the 3G_OPT is suppsoed to do? Is
> this "optimzed for 1GB Real RAM"? Should this be something like "2.5G"
> instead?

Hmm I thought it was obvious with the description in paranthesis after
the option. Basically the option is just an optimized default for 1GB of
RAM, like the 2G option is tailored for 2GB of low mem on a 2GB machine.

The reason the option exists is of course to leave the default at the
older not-so-great option for 1G of RAM.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


be-mail2006 at lina

Jan 10, 2006, 12:17 PM

Post #42 of 51 (2286 views)
Permalink
Re: 2G memory split [In reply to]

On Tue, Jan 10, 2006 at 08:42:00PM +0100, Jens Axboe wrote:
> Hmm I thought it was obvious with the description in paranthesis after
> the option. Basically the option is just an optimized default for 1GB of
> RAM, like the 2G option is tailored for 2GB of low mem on a 2GB machine.

The description was (for full 1Gb Low Memory) and not (optimized for 1GB
physical RAM) which would be more obvious, yes. However the text could still
explain the consequences.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


axboe at suse

Jan 10, 2006, 12:28 PM

Post #43 of 51 (2273 views)
Permalink
Re: 2G memory split [In reply to]

On Tue, Jan 10 2006, Bernd Eckenfels wrote:
> On Tue, Jan 10, 2006 at 08:42:00PM +0100, Jens Axboe wrote:
> > Hmm I thought it was obvious with the description in paranthesis after
> > the option. Basically the option is just an optimized default for 1GB of
> > RAM, like the 2G option is tailored for 2GB of low mem on a 2GB machine.
>
> The description was (for full 1Gb Low Memory) and not (optimized for 1GB
> physical RAM) which would be more obvious, yes. However the text could still
> explain the consequences.

To me the former is clearer, it tells you that you have one full gig of
low memory. But maybe that's just me.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jengelh at linux01

Jan 10, 2006, 12:42 PM

Post #44 of 51 (2288 views)
Permalink
Re: 2G memory split [In reply to]

>2G/2G is not the only viable alternative. On my 1GB x86 box I'm
>using "lowmem1g" patches for both 2.4 and 2.6, which results in
>2.75G for user-space. I'm sure others have other preferences.
>Any standard option for this should either have several hard-coded
>alternatives, or should support arbitrary values (within reason).
>
>(See http://www.csd.uu.se/~mikpe/linux/patches/*/patch-i386-lowmem1g-*
>if you're interested.)

Hm, Con Kolivas also provided a lowmem1g patch in his set...



Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jan 10, 2006, 12:55 PM

Post #45 of 51 (2275 views)
Permalink
Re: 2G memory split [In reply to]

On Maw, 2006-01-10 at 09:56 -0700, Jeff V. Merkey wrote:
> RH ES uses 4:4 which is ideal and superior to this hack.

Its a non trivial trade-off. 4/4 lets you run very large physical memory
systems much more efficiently than usual but you pay a cost on syscalls
and some other events when using the majority of processors. The 4/4
tricks also give most emulations (eg Qemu) serious heartburn trying to
emulate %cr3 reloading via mmap and other interfaces with high overhead
in relative terms.

Of course AMD64 kind of shot the problem in the head once and for all.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


axboe at suse

Jan 10, 2006, 1:02 PM

Post #46 of 51 (2279 views)
Permalink
Re: 2G memory split [In reply to]

On Tue, Jan 10 2006, Jeff V. Merkey wrote:
> Alan Cox wrote:
>
> >On Maw, 2006-01-10 at 09:56 -0700, Jeff V. Merkey wrote:
> >
> >
> >>RH ES uses 4:4 which is ideal and superior to this hack.
> >>
> >>
> >
> >Its a non trivial trade-off. 4/4 lets you run very large physical memory
> >systems much more efficiently than usual but you pay a cost on syscalls
> >and some other events when using the majority of processors. The 4/4
> >tricks also give most emulations (eg Qemu) serious heartburn trying to
> >emulate %cr3 reloading via mmap and other interfaces with high overhead
> >in relative terms.
> >
> >Of course AMD64 kind of shot the problem in the head once and for all.
> >
> >
> >
>
> Yep, they sure did. Seriously, the 4:4 option should also be present
> along with 3:1 and 2:2
> splits. You should merge your RH work into this patch and allow both.
> It would save me one less
> patch to maintain off the tree.

You can't compare the two patches, saying that 4:4 should go in because
configurable page offsets is merged is nonsense.

Note that I'm not advocating against 4:4 as such, I have no real
oppinion on that. It has its uses for sure, while it comes with a cost
for others.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kernel at kolivas

Jan 10, 2006, 4:25 PM

Post #47 of 51 (2280 views)
Permalink
Re: 2G memory split [In reply to]

On Wed, 11 Jan 2006 07:42 am, Jan Engelhardt wrote:
> >2G/2G is not the only viable alternative. On my 1GB x86 box I'm
> >using "lowmem1g" patches for both 2.4 and 2.6, which results in
> >2.75G for user-space. I'm sure others have other preferences.
> >Any standard option for this should either have several hard-coded
> >alternatives, or should support arbitrary values (within reason).
> >
> >(See http://www.csd.uu.se/~mikpe/linux/patches/*/patch-i386-lowmem1g-*
> >if you're interested.)
>
> Hm, Con Kolivas also provided a lowmem1g patch in his set...

I was under the impression that breaking the ABI was a nono and such a patch
would never be considered for mainline. Guess I was wrong. However mine only
offered a split suitable for 1GB of ram whereas this is offering all that and
steak knives too.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


be-news06 at lina

Jan 11, 2006, 12:39 AM

Post #48 of 51 (2276 views)
Permalink
Re: 2G memory split [In reply to]

Jens Axboe <axboe [at] suse> wrote:
> To me the former is clearer, it tells you that you have one full gig of
> low memory. But maybe that's just me.

It still does not describe what the consequences, especiall the difference
to the non-optimized case is. When do you want to use it, and when not.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


axboe at suse

Jan 11, 2006, 2:06 AM

Post #49 of 51 (2283 views)
Permalink
Re: 2G memory split [In reply to]

On Wed, Jan 11 2006, Bernd Eckenfels wrote:
> Jens Axboe <axboe [at] suse> wrote:
> > To me the former is clearer, it tells you that you have one full gig of
> > low memory. But maybe that's just me.
>
> It still does not describe what the consequences, especiall the difference
> to the non-optimized case is. When do you want to use it, and when not.

Please, I told you before in this thread, don't drop people from the cc
list!

But it does explain that, it says full 1g low memory support. So you
have one full gig of low memory, compared to the default setting.
Describing this in painstakingly more detail it of course possible, but
as the help text mentions, if you are not sure then you better leave
this option at its default setting.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dev at sw

Apr 10, 2006, 7:11 AM

Post #50 of 51 (2274 views)
Permalink
Re: 2G memory split [In reply to]

>> +#if defined(CONFIG_DEFAULT_3G)
>> +#define __PAGE_OFFSET_RAW (0xC0000000)
>> +#elif defined(CONFIG_DEFAULT_3G_OPT)
>> +#define __PAGE_OFFSET_RAW (0xB0000000)
>> +#elif defined(CONFIG_DEFAULT_2G)
>> +#define __PAGE_OFFSET_RAW (0x78000000)
>> +#elif defined(CONFIG_DEFAULT_1G)
>> +#define __PAGE_OFFSET_RAW (0x40000000)
>> +#else
>> +#error "Bad user/kernel offset"
>> +#endif
>> +
>> #ifdef __ASSEMBLY__
>> -#define __PAGE_OFFSET (0xC0000000)
>> +#define __PAGE_OFFSET __PAGE_OFFSET_RAW
>> #define __PHYSICAL_START CONFIG_PHYSICAL_START
>> #else
>> -#define __PAGE_OFFSET (0xC0000000UL)
>> +#define __PAGE_OFFSET ((unsigned long)__PAGE_OFFSET_RAW)
>> #define __PHYSICAL_START ((unsigned long)CONFIG_PHYSICAL_START)
>> #endif
>> #define __KERNEL_START (__PAGE_OFFSET + __PHYSICAL_START)
>
> Changing PAGE_OFFSET this way would break at least Valgrind (the latest
> release 3.1.0 by default is statically linked at address 0xb0000000, and
> PIE support does not seem to be present in that release). I remember
> that similar changes were also breaking Lisp implementations (cmucl,
> sbcl), however, I am not really sure about this.
it also breaks some java versions, so we use 3:4 Gb split in OpenVZ, but
redhat still uses 4:4 in enterprise version, so number of such
applications should decrease :)

Thanks,
Kirill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 3 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.