From: Gilles Pokam <pokam@cs.tu-berlin.de>
To: Linux-MM@kvack.org
Subject: mmap() for a cluster of pages
Date: Mon, 26 Oct 1998 12:44:11 +0100 (MET) [thread overview]
Message-ID: <199810261144.MAA12564@faun.cs.tu-berlin.de> (raw)
Hi,
I'm trying to developp my own driver. The problem is that i have to use a
large amount of contiguous memory. For this purpose, in the __get_free_pages()
function, i use an order of 4 (for example).
I have implemented the mmap(), nopage(), open() and release() operations of
the vma and file structures. Like mentionned in the book of Alessandro Rubini,
"Device Driver for Linux", when using more than one page size, the mmap()
is only able to mmap the first page of a page cluster.
I have tried to play with the usage count of the page, but i didn't succeed.
The problem is that, i don't think i have well understand what happens whith
the usage count when a page cluster is mapped !
That is how i was thinking:
I use __get_free_pages to allocates the memory, so the usage count of the
first page in the cluster is already incremented to 1, the rest are zero.
When mmap() calls the nopage() method to retrieve the faulting address, the
later also increments the usage count of the first page (count = 2).After
that, by the next call, the whole block is unloaded because the count of the
other page are 0. So i have tried to increment the usage count of the other
page in the open() method, before the nopage() as been called due to a
faulting address, but it didn't help me!
What happens exactly by the call of the mmap() ? Which steps are involved and
which function increments or decrements the usage count ?
I know for example that the whole block is unloaded after the first call
because the usage count of the other page are somewhere dropped to zero
(by the munmap ??), but i don't know when this step occurs during the mmap()
call.
I will be very honor to receive some information about it.
Thanx,
--
/_/_/_/_/_/_/_/_/_/_/_/_/_//_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
POKAM TIENTCHEU Gilles,
Technical University Berlin | Room : FR 2068
Secretariat FR 2-2 | Voice: 030 - 314 73116
Franklinstrasse 28/29 , D-10587 Berlin | Email: pokam@cs.tu-berlin.de
/_/_/_/_/_/_/_/_/_/_/_/_/_//_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next reply other threads:[~1998-10-26 11:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-10-26 11:44 Gilles Pokam [this message]
1998-10-26 17:39 ` Benjamin C.R. LaHaise
1998-10-30 15:58 ` Stephen C. Tweedie
1998-10-30 18:57 ` Alan Cox
1998-10-30 19:18 ` Benjamin C.R. LaHaise
1998-10-30 20:34 ` Alan Cox
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=199810261144.MAA12564@faun.cs.tu-berlin.de \
--to=pokam@cs.tu-berlin.de \
--cc=Linux-MM@kvack.org \
/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