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>
next prev parent 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