Re: Stack at high memory locations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you for pointing out my mistakes.....it helped to improve my
understanding......and I have learned something!!!

On Tue, May 6, 2008 at 1:53 AM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote:
> On 05-05-08 18:03, Peter Teoh wrote:
>
>
> >  Specifically, if u cat /proc/iomem:
> >
> > /proc>cat iomem
> >
>
> > e0000000-efffffff : PCI MMCONFIG 0
> >  e0000000-efffffff : pnp 00:0e
> >
>
> > And u can see that the 0xe000000 is occupied by someone else.
> >
>
>  Please be aware that /proc/iomem lists physical addresses, while his
> request was for availability of a virtual address.
>

I was aware of the difference, that is why before I posted, I referred
to LDD3, and found this mapping between /proc/*/maps (which is virtual
address) and iomem.   And since Greg in the book speaked as if the two
address are the same (they are identical in the first place - could it
be due to identity mapping for the low mem?   I suspect so.....) and
that's where I deduced that it is virtual memory.

Here (the whole paragraph under "The mmap Device Operation"):

http://people.freedesktop.org/~nagappan/LDD3/LDD3.html

Ok...logically it should physical address....being IOMEM...and being
process independent....


>  The big problem with 0xe0000000 is that it's 512M into kernelspace on a
> standard 32-bit architecture.
>
>  Rene.
>
>

Specifically zooming into the his last 512M (0xe0000000) thing, let's
look at arch/x86/mm/init_32.c: mem_init() - the output is in dmesg:

virtual kernel memory layout:
    fixmap  : 0xffc54000 - 0xfffff000   (3756 kB)
    pkmap   : 0xff400000 - 0xff800000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff3fe000   ( 107 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc0769000 - 0xc07a6000   ( 244 kB)
      .data : 0xc06344ed - 0xc0762ac0   (1209 kB)
      .text : 0xc0400000 - 0xc06344ed   (2257 kB)

And as mem_init() (arch/x86/mm/init_32.c) has partitioned the memory -
the range that OP wanted was 0xe0000000 which in in the kernel virtual
memory region, (as Rene has said), so definitely it is not allowed for
userspace stack usage....which is what setup_arg_pages() is doing --->
per process userspace stack setup.    And his "original 0xc0000000" is
also in kernel range.....which is in the .text range of the kernel
image....

but implementing userspace stack at 0xe000000 is also possible as
well....first u have to reserve it early as in mem_init(), when
multi-CPU is still not interferring each other....then u need to setup
the pagetable for that mapping....and then setting the pageattributes
labelling for the memory....technically and theoretically
possible.....even better still is it technically possible to do this:

if i am in kernel space....access 0xe000000 will immediate use one set
of page table for it....and if in userspace....accessing 0xe000000
will immediately use another pagetable.....it can be confusing....but
I think it can be done.

A good analogy for this will be the 4g-4g split....lots of tlb
flushing resulting in bad performance.....but just focusing on
0xe0000000 ...it may not be so bad.....

Looking forward to sharing.....this is fun :-).....

-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux