* mmap() for a cluster of pages
@ 1998-10-26 11:44 Gilles Pokam
1998-10-26 17:39 ` Benjamin C.R. LaHaise
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Pokam @ 1998-10-26 11:44 UTC (permalink / raw)
To: Linux-MM
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmap() for a cluster of pages
1998-10-26 11:44 mmap() for a cluster of pages Gilles Pokam
@ 1998-10-26 17:39 ` Benjamin C.R. LaHaise
1998-10-30 15:58 ` Stephen C. Tweedie
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin C.R. LaHaise @ 1998-10-26 17:39 UTC (permalink / raw)
To: Gilles Pokam; +Cc: sct, Linux-MM
On Mon, 26 Oct 1998, Gilles Pokam wrote:
> 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.
[...]
Argh, that too much work. Try this instead:
a. allocate buffer when you device is first open()ed and
set the PG_reserved bit for each page in the cluster
-> remember to undo this before freeing the pages
b. us the standard remap_page_range technique to implement mmap.
Note that you should'nt need to implement any vm_ops as the
zap_pte_range call in do_mmap will do the Right Thing for you.
Methinks this KISS approach is easiest, otherwise you have to set
VM_LOCKED in the vma and prevent people from touching it, which just isn't
quite as simple.
Stephen, in replying to this, I glanced at the sound driver's mmap
routine. They use an order > 0 buffer that they map, but don't do
anything to prevent its being touched by the swap routines. My guess is
simply that noone's encountered this bug before, but it's there. If you
want, I'll submit a patch and scan the kernel for other instances of the
same problem. Also, is PG_reserved the best flag for this case?
-ben
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmap() for a cluster of pages
1998-10-26 17:39 ` Benjamin C.R. LaHaise
@ 1998-10-30 15:58 ` Stephen C. Tweedie
1998-10-30 18:57 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Stephen C. Tweedie @ 1998-10-30 15:58 UTC (permalink / raw)
To: Benjamin C.R. LaHaise; +Cc: Gilles Pokam, sct, Linux-MM, Alan Cox
Hi,
On Mon, 26 Oct 1998 12:39:33 -0500 (EST), "Benjamin C.R. LaHaise" <blah@kvack.org> said:
> Stephen, in replying to this, I glanced at the sound driver's mmap
> routine. They use an order > 0 buffer that they map, but don't do
> anything to prevent its being touched by the swap routines.
I'm not sure quite which bit of the sound code you mean. I can't see
anything wrong. When we create a sound buffer (drivers/sound/dmabuf.c),
we explicitly set PG_reserved on every page in the buffer. In
remap_page_range, there is the test
mapnr = MAP_NR(__va(phys_addr));
if (mapnr >= max_mapnr || PageReserved(mem_map+mapnr))
set_pte(pte, mk_pte_phys(phys_addr, prot));
which means that we won't do a remap on any page unless that page is
already protected against being seen by the swapper. I think we're
quite safe here.
> My guess is simply that noone's encountered this bug before, but it's
> there.
We should be OK. Alan will no doubt scream if I'm wrong here.
> Also, is PG_reserved the best flag for this case?
Absolutely, it's the only flag we test for consistently when playing
silly buggers with page-present page table entries.
--Stephen
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmap() for a cluster of pages
1998-10-30 15:58 ` Stephen C. Tweedie
@ 1998-10-30 18:57 ` Alan Cox
1998-10-30 19:18 ` Benjamin C.R. LaHaise
0 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 1998-10-30 18:57 UTC (permalink / raw)
To: Stephen C. Tweedie; +Cc: blah, pokam, Linux-MM, number6
> > My guess is simply that noone's encountered this bug before, but it's
> > there.
>
> We should be OK. Alan will no doubt scream if I'm wrong here.
It seems to be ok. All the bug reports in sound currently are quite
different things
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmap() for a cluster of pages
1998-10-30 18:57 ` Alan Cox
@ 1998-10-30 19:18 ` Benjamin C.R. LaHaise
1998-10-30 20:34 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin C.R. LaHaise @ 1998-10-30 19:18 UTC (permalink / raw)
To: Alan Cox; +Cc: Stephen C. Tweedie, pokam, Linux-MM, number6
On Fri, 30 Oct 1998, Alan Cox wrote:
> > > My guess is simply that noone's encountered this bug before, but it's
> > > there.
> >
> > We should be OK. Alan will no doubt scream if I'm wrong here.
>
> It seems to be ok. All the bug reports in sound currently are quite
> different things
I was mistaken; all's well. The 2.0 code wraps this in a mem_map_reserve
which my eyes blindly skipped. Other code performing the same trick looks
right too (the bttv driver; the fb stuff looks like it has its buffers
outside of normal RAM).
-ben
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mmap() for a cluster of pages
1998-10-30 19:18 ` Benjamin C.R. LaHaise
@ 1998-10-30 20:34 ` Alan Cox
0 siblings, 0 replies; 6+ messages in thread
From: Alan Cox @ 1998-10-30 20:34 UTC (permalink / raw)
To: Benjamin C.R. LaHaise; +Cc: alan, sct, pokam, Linux-MM, number6
> which my eyes blindly skipped. Other code performing the same trick looks
> right too (the bttv driver; the fb stuff looks like it has its buffers
> outside of normal RAM).
bttv uses vmalloced pages
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1998-10-30 20:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-10-26 11:44 mmap() for a cluster of pages Gilles Pokam
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox