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 primary
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 addr
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 4G
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 po
** 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 in
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 directl
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,
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 vi
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 p
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, jus
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 th
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 virt
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 the
** 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
> .s
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 Athlo
** 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 GB'
>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. T
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 co
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 tr
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 t
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 a
30 matches
Mail list logo
