From: Pete Wyckoff <pw@osc.edu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Ken Nicholson <knicholson@corp.iready.com>,
Venkateshr@ami.com, pollard@tomcat.admin.navo.hpc.mil,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Direct Sockets Support??
Date: Tue, 8 May 2001 16:00:56 -0400 [thread overview]
Message-ID: <20010508160056.B15867@quasar.osc.edu> (raw)
In-Reply-To: <034670D62D19D31180990090277A37B701811D72@mercury.corp.iready.com> <E14x7AW-0005bf-00@the-village.bc.nu>
In-Reply-To: <E14x7AW-0005bf-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Tue, May 08, 2001 at 02:04:45PM +0100
alan@lxorguk.ukuu.org.uk said:
> > A couple of concerns I have:
> > * How to pin or pagelock the application buffer without
> > making a kernel transition.
>
> You need to pin them in advance. And pinning pages is _expensive_ so you dont
> want to keep pinning/unpinning pages
I can't convince myself why this has to be so expensive. The
current implementation does this for mlock:
1. Split vma if only a subset of the pages are being locked.
2. Mark bit in vma.
3. Make sure the pages are in core.
That third step has the potential of being the most expensive,
as changing the page tables requires invalidating the TLBs on all
processors. Currently make_pages_present() does the work for 3.
But in the case of an application which fits in main memory, and
has been running for a while (so all pages are present and
dirty), all you'd really have to do is verify the page tables are
in the proper state and skip the TLB flush, right?
Then 3 turns into a single spin_lock pair for the page_table_lock,
and walking down the page table.
The VMA splitting can be nasty, as it might require a couple of
slab allocations, and doing an AVL insertion. (More nastiness in
the case of shared memory or file mapping, too.) But nothing
like playing with TLBs.
Any reason why make_pages_present() is not the really oversized
hammer it seems to be?
-- Pete
next prev parent reply other threads:[~2001-05-08 20:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <034670D62D19D31180990090277A37B701811D72@mercury.corp.iready.com>
2001-05-08 13:04 ` Alan Cox
2001-05-08 20:00 ` Pete Wyckoff [this message]
2001-05-08 20:18 Venkatesh Ramamurthy
2001-05-08 20:50 ` Alan Cox
2001-05-08 21:32 ` 'Pete Wyckoff'
-- strict thread matches above, loose matches on Subject: below --
2001-05-03 20:55 Venkatesh Ramamurthy
2001-05-03 20:40 Venkatesh Ramamurthy
2001-05-03 21:52 ` Alan Cox
2001-05-03 20:23 Jesse Pollard
2001-05-03 19:25 Venkatesh Ramamurthy
2001-05-03 20:29 ` Alan Cox
2001-05-03 19:23 Jesse Pollard
2001-05-03 18:59 Venkatesh Ramamurthy
2001-05-03 20:17 ` Alan Cox
[not found] <007901c0d3fd$ea3f0880$7253e59b@megatrends.com>
2001-05-03 18: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=20010508160056.B15867@quasar.osc.edu \
--to=pw@osc.edu \
--cc=Venkateshr@ami.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=knicholson@corp.iready.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pollard@tomcat.admin.navo.hpc.mil \
/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
all inboxes | Powered by JetHome®