linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Raghu R. Arur" <rra2002@cs.columbia.edu>
To: Sharath Kodi Udupa <sku@CS.Arizona.EDU>
Cc: linux-mm@kvack.org
Subject: Re: linux vm page sharing
Date: Fri, 7 Nov 2003 20:53:57 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0311072049540.571-100000@beijing.clic.cs.columbia.edu> (raw)
In-Reply-To: <Pine.GSO.4.58.0311071728220.12831@lectura.CS.Arizona.EDU>


  I think the idea you are proposing is already present in linux. If two 
executables are using the same library file, then there wont be two 
instances of the page of that library file..

 The address_space in the page maps to the the inode of the file that the 
page is mapped to (in case of a file mapped file) or it will be NULL for 
non-mapped pages. In 2.6 mm, the pages that hold the page table entries of 
a process use this mapping to map to the mm_struct of that process.

 HTH,
 Raghu

On Fri, 7 Nov 2003, Sharath Kodi Udupa wrote:

> hi,
> 
> i am trying to implement a system where different processes can share
> pages, this means that not only same executables, but different
> executables , but when the pages required are same.
> but i see in the linux page structure, it keeps a pointer to the
> address_space mapping, but now since if the second process also needs to
> share the page,this wont be the same mapping. so i am planning to add the
> page table entry to the second process, but to leave the
> struct address_space *mapping pointer to whatever it was earlier. I plan
> to do this since, i dont really understand how this is used and also have
> gone through the code to understand it. What significance does this hold?
> 
> any pointers is greatly appreciated
> 
> regards,
> 
> Sharath K Udupa
> Graduate Student,
> Dept. of Computer Science,
> University of Arizona.
> sku@cs.arizona.edu
> http://www.cs.arizona.edu/~sku
> 
> "Sometimes I think the surest sign that intelligent life exists
> elsewhere in the universe is that none of it has tried to contact us."
> --Calvin, The Indispensable Calvin and Hobbes
> 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2003-11-08  1:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-08  0:35 Sharath Kodi Udupa
2003-11-08  1:53 ` Raghu R. Arur [this message]
2003-11-10 14:45 Mark_H_Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0311072049540.571-100000@beijing.clic.cs.columbia.edu \
    --to=rra2002@cs.columbia.edu \
    --cc=linux-mm@kvack.org \
    --cc=sku@CS.Arizona.EDU \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox