Petr Vandrovec writes:
> Sure it does not. Selectors point to linear addresses, before passing them
> through pagetables. You have 32+14 bits of virtual address (32 = offset,
> 14 = valid bits in selector), which are translated, together with
> offset, to 32 bit linear address. This 32bit linear
Petr Vandrovec writes:
Sure it does not. Selectors point to linear addresses, before passing them
through pagetables. You have 32+14 bits of virtual address (32 = offset,
14 = valid bits in selector), which are translated, together with
offset, to 32 bit linear address. This 32bit linear
BTW, this fork program did appear to kill about 2 sun servers here...
The linux kernel v2.2.16 that they were running survived fine.
On Thu, 12 Oct 2000, Richard B. Johnson wrote:
> On Thu, 12 Oct 2000, Oliver Xymoron wrote:
>
> > On Wed, 11 Oct 2000, Kiril Vidimce wrote:
> >
> > > My
BTW, this fork program did appear to kill about 2 sun servers here...
The linux kernel v2.2.16 that they were running survived fine.
On Thu, 12 Oct 2000, Richard B. Johnson wrote:
On Thu, 12 Oct 2000, Oliver Xymoron wrote:
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
My primary concern
Timur Tabi wrote:
> I understand that a normal virtual address (i.e. a pointer) can only address a
> single 32-bit (4GB) memory block. My point was that by also using more than
> one 16-bit selector, you can have multiple 4GB areas. So for instance,
> 1000: can point to one physical
On Fri, 13 Oct 2000, Timur Tabi wrote:
> ** Reply to message from Alexander Viro <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 15:25:31 -0400 (EDT)
>
>
> > Ditto with PAE: 16:32->32->36.
> > In _all_ cases you are limited by the size of linear address. I.e. all
> > address modes are limited to
On Fri, 13 Oct 2000, Timur Tabi wrote:
> I understand that a normal virtual address (i.e. a pointer) can only address a
> single 32-bit (4GB) memory block. My point was that by also using more than
> one 16-bit selector, you can have multiple 4GB areas. So for instance,
> 1000: can
** Reply to message from Alexander Viro <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
15:25:31 -0400 (EDT)
> Ditto with PAE: 16:32->32->36.
> In _all_ cases you are limited by the size of linear address. I.e. all
> address modes are limited to 4Gb. All you can get from PAE is placing of
> these 4Gb
On Fri, 13 Oct 2000, Timur Tabi wrote:
> ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 20:44:19 +0200 (CEST)
>
>
> > processes are not limited to a single segment, eg. Wine uses nonstandard
> > segments. But as i said, using multiple segments does not let you
** Reply to message from Brian Gerst <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
15:07:42 -0400
> You missed the point. The layering on the X86 memory managment is such:
>
>Segment
> |
> Virtual Address<- limited to 32 bits
> |
> Physical Address
>
> Segmentation never
On Fri, 13 Oct 2000, Chris Swiedler wrote:
>
> Why is it that a user process can't intentionally switch segments?
> Dereferencing a 32-bit address causes the address to be calculated using the
> "current" segment descriptor, right? It seems to me that a process could set
> a new segment
Timur Tabi wrote:
>
> ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 20:44:19 +0200 (CEST)
>
> > processes are not limited to a single segment, eg. Wine uses nonstandard
> > segments. But as i said, using multiple segments does not let you out of
> > 32 bits of
On 13 Oct 00 at 13:42, Timur Tabi wrote:
> ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
> 20:44:19 +0200 (CEST)
> > processes are not limited to a single segment, eg. Wine uses nonstandard
> > segments. But as i said, using multiple segments does not let you out of
On Fri, 13 Oct 2000, Timur Tabi wrote:
> Sure it does, just like segments let 16-bit apps access more than 64KB of
> memory. If you have two selectors, each one can point to a different physical
> base address, and IIRC, the size of the physical address base can be 36 bits.
> That gives you 16
Chris Swiedler wrote:
>
> > no, x86 virtual memory is 32 bits - segmentation only provides a way to
> > segment this 4GB virtual memory, but cannot extend it. Under Linux there
> > is 3GB virtual memory available to user-space processes.
> >
> > this 3GB virtual memory does not have to be mapped
** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000
20:44:19 +0200 (CEST)
> processes are not limited to a single segment, eg. Wine uses nonstandard
> segments. But as i said, using multiple segments does not let you out of
> 32 bits of virtual memory.
Sure it does,
On Fri, 13 Oct 2000, Chris Swiedler wrote:
> Why is it that a user process can't intentionally switch segments?
> Dereferencing a 32-bit address causes the address to be calculated
> using the "current" segment descriptor, right? It seems to me that a
> process could set a new segment selector,
> no, x86 virtual memory is 32 bits - segmentation only provides a way to
> segment this 4GB virtual memory, but cannot extend it. Under Linux there
> is 3GB virtual memory available to user-space processes.
>
> this 3GB virtual memory does not have to be mapped to the same physical
> pages all
On Fri, 13 Oct 2000, Chris Swiedler wrote:
Why is it that a user process can't intentionally switch segments?
Dereferencing a 32-bit address causes the address to be calculated
using the "current" segment descriptor, right? It seems to me that a
process could set a new segment selector, in
** Reply to message from Ingo Molnar [EMAIL PROTECTED] on Fri, 13 Oct 2000
20:44:19 +0200 (CEST)
processes are not limited to a single segment, eg. Wine uses nonstandard
segments. But as i said, using multiple segments does not let you out of
32 bits of virtual memory.
Sure it does, just
On Fri, 13 Oct 2000, Timur Tabi wrote:
Sure it does, just like segments let 16-bit apps access more than 64KB of
memory. If you have two selectors, each one can point to a different physical
base address, and IIRC, the size of the physical address base can be 36 bits.
That gives you 16
On 13 Oct 00 at 13:42, Timur Tabi wrote:
** Reply to message from Ingo Molnar [EMAIL PROTECTED] on Fri, 13 Oct 2000
20:44:19 +0200 (CEST)
processes are not limited to a single segment, eg. Wine uses nonstandard
segments. But as i said, using multiple segments does not let you out of
32
** Reply to message from Brian Gerst [EMAIL PROTECTED] on Fri, 13 Oct 2000
15:07:42 -0400
You missed the point. The layering on the X86 memory managment is such:
Segment
|
Virtual Address- limited to 32 bits
|
Physical Address
Segmentation never directly gives you
On Fri, 13 Oct 2000, Timur Tabi wrote:
I understand that a normal virtual address (i.e. a pointer) can only address a
single 32-bit (4GB) memory block. My point was that by also using more than
one 16-bit selector, you can have multiple 4GB areas. So for instance,
1000: can point
On Fri, 13 Oct 2000, Timur Tabi wrote:
** Reply to message from Alexander Viro [EMAIL PROTECTED] on Fri, 13 Oct 2000
15:25:31 -0400 (EDT)
Ditto with PAE: 16:32-32-36.
In _all_ cases you are limited by the size of linear address. I.e. all
address modes are limited to 4Gb. All you
On Thu, Oct 12, 2000 at 07:19:32PM -0400, Dan Maas wrote:
> The memory map of a user process on x86 looks like this:
>
> -
> KERNEL (always present here)
> 0xC000
> -
> 0xBFFF
> STACK
> -
> MAPPED FILES (incl. shared libs)
> 0x4000
>
The memory map of a user process on x86 looks like this:
-
KERNEL (always present here)
0xC000
-
0xBFFF
STACK
-
MAPPED FILES (incl. shared libs)
0x4000
-
HEAP (brk()/malloc())
EXECUTABLE CODE
0x08048000
-
On Thu, 12 Oct 2000, Timur Tabi wrote:
> Of course, you could define a pointer to be a 48-bit value, but I
> doubt that would really work.
no, x86 virtual memory is 32 bits - segmentation only provides a way to
segment this 4GB virtual memory, but cannot extend it. Under Linux there
is 3GB
Timur Tabi writes:
> ** Reply to message from Jeff Epler <[EMAIL PROTECTED]> on Thu, 12 Oct 2000
> 13:08:19 -0500
> > What the support for >4G of memory on x86 is about, is the "PAE", Page Address
> > Extension, supported on P6 generation of machines, as well as on Athlons
> > (I think). With
** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on Thu,
12 Oct 2000 15:17:15 -0400 (EDT)
> With ix86 processors in the kernel, you can create multiple segments
> and multiple page-tables.
Does the kernel provide services for this, or will I have to hack up the x86
page tables
> > Am I reading this correctly--the address of the main() function for a
> > process is guaranteed to be the lowest possible virtual address?
> >
> > chris
> >
>
> It is one of the lowest. The 'C' runtime library puts section
> .text (the code) first, then .data, then .bss, then .stack. The
>
On Thu, 12 Oct 2000, Timur Tabi wrote:
> ** Reply to message from Jeff Epler <[EMAIL PROTECTED]> on Thu, 12 Oct 2000
> 13:08:19 -0500
>
>
> > What the support for >4G of memory on x86 is about, is the "PAE", Page Address
> > Extension, supported on P6 generation of machines, as well as on
** Reply to message from Jeff Epler <[EMAIL PROTECTED]> on Thu, 12 Oct 2000
13:08:19 -0500
> What the support for >4G of memory on x86 is about, is the "PAE", Page Address
> Extension, supported on P6 generation of machines, as well as on Athlons
> (I think). With these, the kernel can use >4G
On Thu, Oct 12, 2000 at 10:36:38AM -0700, Kiril Vidimce wrote:
> Allocate = malloc(). The process needs to be able to operate on >4 GB
> chunks of memory. I understand that it's only a 32 bit address space
> which is why I was surprised when I read that Linux 2.4.x will support
> upwards of 64
>On Thu, 12 Oct 2000, Oliver Xymoron wrote:
>> On Wed, 11 Oct 2000, Kiril Vidimce wrote:
>>
>> > My primary concern is whether a process can allocate more than 4 GB of
>> > memory, rather than just be able to use more than 4 GB of physical
>> > memory in the system.
>>
>> Define allocate.
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
>
> Hi there,
>
> I am trying to find out more information on large memory support (> 4 GB)
> for Linux IA32. Is there a document that elaborates on what is supported
> and what isn't and how this scheme actually works in the kernel?
>
> My primary
On Thu, 12 Oct 2000, Oliver Xymoron wrote:
> On Wed, 11 Oct 2000, Kiril Vidimce wrote:
>
> > My primary concern is whether a process can allocate more than 4 GB of
> > memory, rather than just be able to use more than 4 GB of physical
> > memory in the system.
>
> Define allocate. There are
On Thu, 12 Oct 2000, Oliver Xymoron wrote:
> On Wed, 11 Oct 2000, Kiril Vidimce wrote:
>
> > My primary concern is whether a process can allocate more than 4 GB of
> > memory, rather than just be able to use more than 4 GB of physical
> > memory in the system.
>
> Define allocate. There are
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
> My primary concern is whether a process can allocate more than 4 GB of
> memory, rather than just be able to use more than 4 GB of physical
> memory in the system.
Define allocate. There are tricks you can play, but userspace is still a
flat 32-bit
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
My primary concern is whether a process can allocate more than 4 GB of
memory, rather than just be able to use more than 4 GB of physical
memory in the system.
Define allocate. There are tricks you can play, but userspace is still a
flat 32-bit
On Thu, 12 Oct 2000, Oliver Xymoron wrote:
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
My primary concern is whether a process can allocate more than 4 GB of
memory, rather than just be able to use more than 4 GB of physical
memory in the system.
Define allocate. There are tricks you
On Thu, 12 Oct 2000, Oliver Xymoron wrote:
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
My primary concern is whether a process can allocate more than 4 GB of
memory, rather than just be able to use more than 4 GB of physical
memory in the system.
Define allocate. There are tricks you
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
Hi there,
I am trying to find out more information on large memory support ( 4 GB)
for Linux IA32. Is there a document that elaborates on what is supported
and what isn't and how this scheme actually works in the kernel?
My primary concern is
On Thu, 12 Oct 2000, Oliver Xymoron wrote:
On Wed, 11 Oct 2000, Kiril Vidimce wrote:
My primary concern is whether a process can allocate more than 4 GB of
memory, rather than just be able to use more than 4 GB of physical
memory in the system.
Define allocate. There are tricks
On Thu, Oct 12, 2000 at 10:36:38AM -0700, Kiril Vidimce wrote:
Allocate = malloc(). The process needs to be able to operate on 4 GB
chunks of memory. I understand that it's only a 32 bit address space
which is why I was surprised when I read that Linux 2.4.x will support
upwards of 64 GB's of
** Reply to message from Jeff Epler [EMAIL PROTECTED] on Thu, 12 Oct 2000
13:08:19 -0500
What the support for 4G of memory on x86 is about, is the "PAE", Page Address
Extension, supported on P6 generation of machines, as well as on Athlons
(I think). With these, the kernel can use 4G of
On Thu, 12 Oct 2000, Timur Tabi wrote:
** Reply to message from Jeff Epler [EMAIL PROTECTED] on Thu, 12 Oct 2000
13:08:19 -0500
What the support for 4G of memory on x86 is about, is the "PAE", Page Address
Extension, supported on P6 generation of machines, as well as on Athlons
(I
Am I reading this correctly--the address of the main() function for a
process is guaranteed to be the lowest possible virtual address?
chris
It is one of the lowest. The 'C' runtime library puts section
.text (the code) first, then .data, then .bss, then .stack. The
.stack section
** Reply to message from "Richard B. Johnson" [EMAIL PROTECTED] on Thu,
12 Oct 2000 15:17:15 -0400 (EDT)
With ix86 processors in the kernel, you can create multiple segments
and multiple page-tables.
Does the kernel provide services for this, or will I have to hack up the x86
page tables
Timur Tabi writes:
** Reply to message from Jeff Epler [EMAIL PROTECTED] on Thu, 12 Oct 2000
13:08:19 -0500
What the support for 4G of memory on x86 is about, is the "PAE", Page Address
Extension, supported on P6 generation of machines, as well as on Athlons
(I think). With these, the
On Thu, 12 Oct 2000, Timur Tabi wrote:
Of course, you could define a pointer to be a 48-bit value, but I
doubt that would really work.
no, x86 virtual memory is 32 bits - segmentation only provides a way to
segment this 4GB virtual memory, but cannot extend it. Under Linux there
is 3GB
The memory map of a user process on x86 looks like this:
-
KERNEL (always present here)
0xC000
-
0xBFFF
STACK
-
MAPPED FILES (incl. shared libs)
0x4000
-
HEAP (brk()/malloc())
EXECUTABLE CODE
0x08048000
-
On Thu, Oct 12, 2000 at 07:19:32PM -0400, Dan Maas wrote:
The memory map of a user process on x86 looks like this:
-
KERNEL (always present here)
0xC000
-
0xBFFF
STACK
-
MAPPED FILES (incl. shared libs)
0x4000
-
53 matches
Mail list logo
