All of lore.kernel.org
 help / color / mirror / Atom feed
* Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
@ 2005-07-18  4:42 vamsi krishna
  2005-07-18 11:45 ` Alan Cox
  0 siblings, 1 reply; 2+ messages in thread
From: vamsi krishna @ 2005-07-18  4:42 UTC (permalink / raw)
  To: alan; +Cc: linux-kernel

Hello Alan, mm-hackers,

I have been working this idea of increasing virtual address space of a
process with the help of secondary memory. At first this may seem like
the same virtual memory concept but its not the case.

Imagine all the virtual address the compiler generates while creating
the binary as relocatable offsets on the disk, and the application
specific runtime mmaps and munmaps these dynamically.

I was searching a lot about work on this, and found your reply where
you say that we can increase the virtual address space by mmaping and
munmaping programatically ourself.

So is the bigmem kernel implement this? may be  you can give me some
insight into this.

Some inputs on this would be highly appreciated.

Sincerely,
Vamsi kundeti. 

PS: Please refer this kernel mailing list email.


<--------------------------------------------------SNIP--------------------------------------------------------------------------->
Re: BIGMEM kernel question
From: Alan Cox (alan@lxorguk.ukuu.org.uk)
Date: Fri Jul 06 2001 - 16:46:16 EST



> Ahh. That makes sense. So how can I change the chunk size from 64k to
> something higher (I assume I could set it to 128k to effectively double
> that 3GB to 6GB)?

I think you misunderstand. If you want more than 3Gb you will have to map and
unmap stuff yourself. You only have 3Gb of per process address space due to
x86 weaknesses (lack of seperate kernel/user spaces without tlb flush
overhead nightmares)

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

    * Next message: Donald Becker: "Re: why this 1ms delay in
mdio_read? (cont'd from "are ioctl calls supposed to take this
long?")"
    * Previous message: Rik van Riel: "Re: BIGMEM kernel question"
    * In reply to: Eric Anderson: "Re: BIGMEM kernel question"
    * Next in thread: Brian Gerst: "Re: BIGMEM kernel question"
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
<------------------------------------------------------SNIP----------------------------------------------------------------------------->

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
  2005-07-18  4:42 Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory vamsi krishna
@ 2005-07-18 11:45 ` Alan Cox
  0 siblings, 0 replies; 2+ messages in thread
From: Alan Cox @ 2005-07-18 11:45 UTC (permalink / raw)
  To: vamsi krishna; +Cc: linux-kernel

On Llu, 2005-07-18 at 10:12 +0530, vamsi krishna wrote:
> I was searching a lot about work on this, and found your reply where
> you say that we can increase the virtual address space by mmaping and
> munmaping programatically ourself.

Its something a few giant applications do with data sets and the trick
of using shared memory segments works on most Linux or Unixlike systems.
It's almost a historical note now. With 64bit processors its no longer
worth the pain


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-07-18 11:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-18  4:42 Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory vamsi krishna
2005-07-18 11:45 ` Alan Cox

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.