Re: Hello

Re: Hello

[Manfred Spraul, Stephen C. Tweedie]

>The newer addressing mode is the 3-level page tables available in
>PIIIs (and in later stepping PIIs, I think), which allow transparent
>access to all of physical memory up to 64G.  That's what I'm aiming
>for.
AFIAK it's the other way around:
the 3-level system is PAE, available since PPro,
and the 2-level system where only 4 MB PTE's can address
memory > 3 GB is the new system added for the P-II Xeon.
I think this mode was only added for WinNT:
Intel wants to support > 4 GB memory,
but the internal MM of NT is 2-level even in Windows-2000.
(according to www.osr.com).

Have you already started with your high-mem patch?

--
    Manfred


--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Stephen C. Tweedie]

Hi,

On Wed, 5 May 1999 17:27:44 +0200, "Manfred Spraul"
<manfreds@colorfullife.com> said:

> Have you already started with your high-mem patch?

Not really -- the bulk of the work is waiting until journaling is
done.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Hello

[Freeman Xiong]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 262 bytes --]

Hello

[Quincy Thompson]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 262 bytes --]

hello

[Orlando Villegas]

[-- Attachment #1: Type: text/plain, Size: 26 bytes --]

    Buy medications Here!

[-- Attachment #2: Type: text/html, Size: 399 bytes --]

Hello

[Lee Montoya]

[-- Attachment #1: Type: text/plain, Size: 26 bytes --]

    Get medications Here!

[-- Attachment #2: Type: text/html, Size: 393 bytes --]

Hello

[Erick Andrade]

[-- Attachment #1: Type: text/plain, Size: 19 bytes --]

    Buy meds Here!

[-- Attachment #2: Type: text/html, Size: 391 bytes --]

hello

[Romeo Grimes]

[-- Attachment #1: Type: text/plain, Size: 21 bytes --]

    Buy viagra Here!

[-- Attachment #2: Type: text/html, Size: 399 bytes --]

Hello

[Melissa Culver]

[-- Attachment #1: Type: text/plain, Size: 19 bytes --]

    Get meds Here!

[-- Attachment #2: Type: text/html, Size: 394 bytes --]

Hello

[Eliza Burke]

[-- Attachment #1: Type: text/plain, Size: 21 bytes --]

    Get viagra Here!

[-- Attachment #2: Type: text/html, Size: 391 bytes --]

hello

[Victoria Metz]

[-- Attachment #1: Type: text/plain, Size: 19 bytes --]

    Get meds Here!

[-- Attachment #2: Type: text/html, Size: 398 bytes --]

hello

[Brad Mcneill]

[-- Attachment #1: Type: text/plain, Size: 21 bytes --]

    Get viagra Here!

[-- Attachment #2: Type: text/html, Size: 352 bytes --]

hello

[Olivia Gilmore]

[-- Attachment #1: Type: text/plain, Size: 26 bytes --]

    Buy medications Here!

[-- Attachment #2: Type: text/html, Size: 359 bytes --]

Hello

[Brian Elias]

Dear Neighbor:

	I'm having a tax problem and I want you to be the beneficiary 
instead of the IRS...

	My business has had a phenomenal year so far in 2001. In fact, 
we've done so well I'm probably going to pay 2 1/2  times more corporate 
taxes than I did last year. And if we make any more money this year, 
the tax problem will only get worse... I'll have to pay even more 
money to the IRS.  

	I have employees who I don't want to lay-off. So in order to keep 
my employees busy and not give more money to the IRS, I've decided on 
a strategy that's so bold ? so daring ? that I doubt anyone else 
would even dare try it.  I have decided to offer windows and siding 
to you, at our basic cost.  In other words, I'm going to offer you 
windows and siding for no personal profit whatsoever!  This will 
increase our expenses thereby decrease our percent of profits. Just 
click the link below to set up an appointment with one of my sales 
representatives today!

	Just point your browser at www.inetwindows2k.com

Brian Elias
President 
Hansons Windows & Siding

P. S. This a one time email offer only good for the next 9 day 
or until we decrease our tax problem.
























**If you wish to have your e-mail removed from our list, please reply to this
email with REMOVE as the subject.


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

Re: Hello

[Manfred Spraul]

I wrote a few hour ago:
>Do you have any details about PSE-36?
I found the description about PSE-36, it's part of the addendum
to Volume 3 of the PII documentation.
(available from http://www.intel.com/design/pentiumii/manuals/)
In summary:
On PII Xeon processors, you can use 4 MB PTE's to map
physical memory from the complete 36 bit address space.
They use the formerly reserved bits in the middle of the PTE
for this. Everything else remains unchanged. Actually, PSE-36 is
always enabled on PII Xeon processors if you enable
the 4 MB page table entries.
The modification only applies to 4 MB pte's, PSE-36 does
not allow you to access high memory with 4 kb PTE's

Please ignore my post about Intel's NT device driver:
It's a simple hack, it allows you to use the remaining memory
as a ramdisk. 

Regards,
    Manfred


--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Manfred Spraul, ak]

>Not even the restriction that a single process cannot use more than 
>4GB-something?

Due to the 32 bit addressing, you can't use more that 4 Gb memory
at the same time.
I think you could create several memory mapped regions,
each e.g. 1 GB and map one at a time. 


Regards,
    Manfred



--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Stephen C. Tweedie]

Hi,

On Sat, 1 May 1999 16:00:01 +0200, "ak@muc.de" <ak@muc.de> said:

> Due to the 32 bit addressing, you can't use more that 4 Gb memory
> at the same time.
> I think you could create several memory mapped regions,
> each e.g. 1 GB and map one at a time. 

Indeed, and that is what (for example) NT's VLM allows.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Manfred Spraul]

From: Stephen C. Tweedie <sct@redhat.com>
>NT's VLM support only gives you access to the high memory if you use a
>special API.  We plan on supporting clean access to all of physical
>memory quite transparently for Linux, without any such restrictions.
Do you plan that for 2.2 or 2.3?
Do you think that this will be backported to 2.2?
If not, then I'll write a quick and dirty shm modification which supports
more memory, and I'll disable swapping for that memory.

A note about VLM:
* VLM is a Microsoft invention for Windows NT on Alpha:
the user mode program is 64 bit, the kernel mostly 32 bit.
Pointers are sign extended by the processor.
A special kernel extension allows user mode processes to
map up to 28 GB memory into the middle of the memory space.
The rest of the OS knows nothing about this memory.
>From the MSDN Library:
>VLM is supported only on processors that directly support
> native 64-bit addressing. At present, these include the
> Compaq DIGITAL AlphaServer processors and specifically
> exclude the Intel 80286, 80386, 80486, Pentium, and
> Pentium II processors. 

* I read something on the Intel website about a kernel extension
which Intel wrote for the Pentium Processor.
If Linux supports more than 2 GB memory on 32 Bit processor,
then the implementation will be similar to that.

Do you have any details about PSE-36?
This seems to be a page table extention for the Xeon CPU's
AFAIK, this is not identical to PAE (available since PPro).
And: AFAIK, there are no chipsets which support > 4 GB
memory for PPro's, so there is no need to support PAE if PSE-36
is easier to implement.

Regards,
    Manfred


--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Stephen C. Tweedie]

Hi,

On Sat, 1 May 1999 15:56:46 +0200, "Manfred Spraul"
<manfreds@colorfullife.com> said:

> Do you have any details about PSE-36?

Yes, the PDF docsets on Intel's developer pages cover it pretty well.

> This seems to be a page table extention for the Xeon CPU's
> AFAIK, this is not identical to PAE (available since PPro).

There are two separate extensions.  Since PPro, the CPUs have
supported large page tables.  Currently these can address 36 bits of
physical memory, but given that you have to deal with it in 4MB or 2MB
chunks, it is much less convenient than normal addressing and cannot
easily be used to support transparently the existing kernel
behaviour. 

The newer addressing mode is the 3-level page tables available in
PIIIs (and in later stepping PIIs, I think), which allow transparent
access to all of physical memory up to 64G.  That's what I'm aiming
for.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Manfred Spraul]

Benjamin C.R. LaHaise <blah@kvack.org> wrote:
>I think someone created patches that make a ramdisk out of the really high
>memory.  Try doing a search of the linux-kernel archives -- I remember
>seeing it withing the past 3 or 4 months.  Hope this helps!
I wrote that patch, but I abandoned it because I think that the performance
would be inacceptable: the data is first cached in the buffer cache,
and later moved into high memory, and if you access the data it's
moved back. I think that the memmove() calls would slow down
the system considerably.

If you need the patch I can send it to you.

But I have a new idea: what about replacing the current 'shm' implementation
with a high memory aware implementation.
* use high memory if high memory is available. We only need a simple
   bitmap for the high-mem. max_mapnr remains 1 or 2 GB, page_map
   is not extended.
* if you have more than 2 Gb memory, then you don't want that the system
    starts to swap out. So there is no need to support swap for that memory.
    This means: no double buffering etc required.
* I haven't yet read the new Xeon page table extentions,
  but perhaps we could support up to 64 GB memory without changing the
  rest of the OS   (Intel could write such a driver for Windows NT,
  I'm sure this is possible for Linux, too).
* it's very easy for the user mode programmers, no new interfaces.

I think that this implementation would required only a few hundred lines.

What do you think about this?

Regards,
    Manfred


--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Benjamin C.R. LaHaise]

On Fri, 30 Apr 1999, Manfred Spraul wrote:

> If you need the patch I can send it to you.

=)  The most memory any of my machines have is 64 megs.  It would be nice
if more developers had systems with 4 gigs of memory...

> But I have a new idea: what about replacing the current 'shm' implementation
> with a high memory aware implementation.

> * it's very easy for the user mode programmers, no new interfaces.
> 
> I think that this implementation would required only a few hundred lines.
> 
> What do you think about this?

The implementation I saw Stephen post about is actually even better: add a
bit to page->flags to indicate that the memory is HIGH memory, which only
gets returned by get_free_page() if the caller inclues a GFP_HIGH_OKAY
flag.  Then, these pages can be used to fill in anonymous user mappings
and shared memory.  Presto chango, maybe a couple of hundred line patch
and you've got support for 4GB on intel, albeit with restrictions.  Then
the Xeon 36 bit page tables are a simple extension from there.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Stephen C. Tweedie]

Hi,

On Fri, 30 Apr 1999 18:12:21 +0200, "Manfred Spraul"
<masp0008@stud.uni-sb.de> said:

> * I haven't yet read the new Xeon page table extentions,
>   but perhaps we could support up to 64 GB memory without changing the
>   rest of the OS   (Intel could write such a driver for Windows NT,
>   I'm sure this is possible for Linux, too).

NT's VLM support only gives you access to the high memory if you use a
special API.  We plan on supporting clean access to all of physical
memory quite transparently for Linux, without any such restrictions.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[ak]

On Fri, Apr 30, 1999 at 02:55:51AM +0200, Stephen C. Tweedie wrote:
> Hi,
> 
> On Fri, 30 Apr 1999 18:12:21 +0200, "Manfred Spraul"
> <masp0008@stud.uni-sb.de> said:
> 
> > * I haven't yet read the new Xeon page table extentions,
> >   but perhaps we could support up to 64 GB memory without changing the
> >   rest of the OS   (Intel could write such a driver for Windows NT,
> >   I'm sure this is possible for Linux, too).
> 
> NT's VLM support only gives you access to the high memory if you use a
> special API.  We plan on supporting clean access to all of physical
> memory quite transparently for Linux, without any such restrictions.

Not even the restriction that a single process cannot use more than 
4GB-something?


-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Stephen C. Tweedie]

Hi,

On Wed, 1 Jan 1997 16:29:19 +0100, ak@muc.de said:
   ^^^^^^^^^^^^^^^

??? Check your clocks!

> On Fri, Apr 30, 1999 at 02:55:51AM +0200, Stephen C. Tweedie wrote:

>> NT's VLM support only gives you access to the high memory if you use a
>> special API.  We plan on supporting clean access to all of physical
>> memory quite transparently for Linux, without any such restrictions.

> Not even the restriction that a single process cannot use more than 
> 4GB-something?

The high memory support will have no new restrictions visible to the
user.  The existing 3GB virtual address space limit will not be
changed.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Hello

[James E. King, III]

I'm not much of a kernel type, but I do have some formal background on OS
working and reading through the Linux-MM site brought back lots of stuff.

Anyway, I am working on a project where we have a large database split into
12 segments, and I want to put some of the indices in those segments into
memory.  The indices for all of the segments takes up about 4 GB.

The database server is a multi-threaded proprietary one that I ported over
to Linux - it already runs on MacOS (yes, true!), NT, Solaris, AIX.

I have a couple of questions (assume I am talking about the latest versions
of any component, like kernel or lilo or ramdisk):

1. If I purchase a Quad Xeon 550 with 4 GB of memory, will Linux work on it?
   (I saw the whole thing about tweaking kernel parameters to change from a 3:1
    split to a 2:2 split)
   Should I just buy 2GB - will I be able to use the extra 2GB?

2. Can I create a large (let's say 1GB) ramdisk or memory filesystem?

Obviously the more index I can fit into memory, the faster the result.

I'd really, really like to use Linux here.  It has proven itself as our
mail/DNS server and hasn't crashed once in over 2 years, where we reboot NT
servers weekly.

I am willing to do some kernel hacking and experimentation.  I have not
been able to find another resource related to large amounts of memory with
Linux.  Hopefully through my experiences I will be able to produce a Linux
VLM-HOWTO!

Thanks.

     _/   _/_/  _/_/_/ _/_/  _/_/         James E. King, III
    _/_/  _/ _/   _/   _/   _/            Aries Systems Corporation
   _/_/_/ _/_/    _/   _/_/  _/_/         200 Sutton Street
   _/  _/ _/ _/   _/   _/       _/        North Andover, MA.  01845
   _/  _/ _/ _/ _/_/_/ _/_/  _/_/         (978) 975-7570
                                          (978) 975-3811 FAX
      <http://www.kfinder.com/>
  Enhancing the Power of Knowledge(r)     jking@ariessys.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Benjamin C.R. LaHaise]

On Wed, 28 Apr 1999, James E. King, III wrote:

> 1. If I purchase a Quad Xeon 550 with 4 GB of memory, will Linux work on it?
>    (I saw the whole thing about tweaking kernel parameters to change from a 3:1
>     split to a 2:2 split)
>    Should I just buy 2GB - will I be able to use the extra 2GB?

You won't be able to use the extra 2GB without some effort.  Current plans
seem to be headed towards keeping the current 3G/1G split.  Fwiw, if
you're going to spend that much money, why not purchase an Alpha?  That
way you'll be able to grow beyond the 4GB as your data grows.

> 2. Can I create a large (let's say 1GB) ramdisk or memory filesystem?

I think someone created patches that make a ramdisk out of the really high
memory.  Try doing a search of the linux-kernel archives -- I remember
seeing it withing the past 3 or 4 months.  Hope this helps!

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Stephen C. Tweedie]

Hi,

On Wed, 28 Apr 1999 11:28:07 -0400, "James E. King, III"
<jking@ariessys.com> said:

> 1. If I purchase a Quad Xeon 550 with 4 GB of memory, will Linux work
>    on it?  (I saw the whole thing about tweaking kernel parameters to
>    change from a 3:1 split to a 2:2 split)

It _will_ work, but by default will only use 1GB.  The most it can use
if you recompile the kernel is 2GB.

However, we have plans to support 64GB cleanly --- watch this space. :)

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Hello

[Manfred Spraul]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

"James E. King, III" wrote:
> 2. Can I create a large (let's say 1GB) ramdisk or memory filesystem?

Is there any reason why rd_size can only be set at system startup,
but not if rd is loaded as a module?

I personally use the attached patch without any problems.

Regards,
	Manfred

[-- Attachment #2: patch_rd_size-2.2.6 --]
[-- Type: application/octet-stream, Size: 383 bytes --]

--- 2.2.6/drivers/block/rd.c	Wed Apr 28 18:13:59 1999
+++ current/drivers/block/rd.c	Fri Apr 30 15:59:26 1999
@@ -100,6 +100,9 @@
  */
 int rd_size = 4096;		/* Size of the RAM disks */
 
+#ifdef MODULE
+MODULE_PARM(rd_size,"i");
+#endif
 #ifndef MODULE
 int rd_doload = 0;		/* 1 = load RAM disk, 0 = don't load */
 int rd_prompt = 1;		/* 1 = prompt for RAM disk, 0 = don't prompt */