From: David Howells <dhowells@redhat.com>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: bryan.wu@analog.com, "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
waltje@uwalt.nl.mugnet.org, "Aubrey Li" <aubreylee@gmail.com>,
netdev@vger.kernel.org, "Andrew Morton" <akpm@osdl.org>,
"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] CONFIG_PACKET_MMAP should depend on MMU
Date: Tue, 10 Apr 2007 13:55:28 +0100 [thread overview]
Message-ID: <9561.1176209728@redhat.com> (raw)
In-Reply-To: <200704091146.32346.rgetz@blackfin.uclinux.org>
Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> David - I know you have been reworking the noMMU vma handling - is there a
> solution to vm_insert_page?
The reason vm_insert_page() is being called, I imagine, is because
packet_mmap() has to insert mappings to an already existing buffer. All it
does is munge the PTEs in that virtual region to point to the buffer.
As long as the buffer is completely contiguous (which I don't know for
certain), then this function can be trivially reduced in NOMMU-mode to
something that just returns the address of the requested part of the buffer.
No remapping would be required.
However... If the buffer is *not* completely contiguous, then you can still
perform mmaps of it - but only where the desired part _is_ contiguous.
Alternatively, you can arrange for the buffer to be completely contiguous
upfront.
Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the latter
case. I don't know that this is a problem; it depends on how things work, and
that I don't know offhand. If someone can give me a simple test program, I
would be able to evaluate it better.
David
next prev parent reply other threads:[~2007-04-10 12:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-09 3:01 [PATCH] CONFIG_PACKET_MMAP should depend on MMU Aubrey Li
2007-04-09 9:50 ` Wu, Bryan
2007-04-09 15:46 ` Robin Getz
2007-04-10 12:55 ` David Howells [this message]
2007-04-10 23:52 ` Robin Getz
2007-04-17 10:36 ` Aubrey Li
2007-04-17 18:30 ` Robin Getz
2007-04-17 19:02 ` David Howells
2007-04-18 15:33 ` David Howells
2007-04-19 0:59 ` Aubrey Li
2007-04-19 9:42 ` David Howells
2007-04-20 4:46 ` Aubrey Li
2007-04-20 7:58 ` David Howells
2007-04-20 8:39 ` Aubrey Li
2007-04-20 8:58 ` David Howells
2007-04-20 9:17 ` Eric Dumazet
2007-04-20 10:43 ` David Howells
2007-04-20 13:14 ` Aubrey Li
2007-04-09 16:55 ` David Miller
2007-04-09 18:43 ` David Miller
2007-04-09 20:08 ` Robin Getz
2007-04-10 2:00 ` Wu, Bryan
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=9561.1176209728@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=aubreylee@gmail.com \
--cc=bryan.wu@analog.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rgetz@blackfin.uclinux.org \
--cc=waltje@uwalt.nl.mugnet.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;
as well as URLs for NNTP newsgroup(s).