Re: Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
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 ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] 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-> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
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 ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] 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- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
