mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "'Pete Wyckoff'" <pw@osc.edu>
To: Venkatesh Ramamurthy <Venkateshr@ami.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Ken Nicholson <knicholson@corp.iready.com>,
	pollard@tomcat.admin.navo.hpc.mil, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Direct Sockets Support??
Date: Tue, 8 May 2001 17:32:57 -0400	[thread overview]
Message-ID: <20010508173257.C15867@quasar.osc.edu> (raw)
In-Reply-To: <1355693A51C0D211B55A00105ACCFE6402B9DEE0@ATL_MS1>
In-Reply-To: <1355693A51C0D211B55A00105ACCFE6402B9DEE0@ATL_MS1>; from Venkateshr@ami.com on Tue, May 08, 2001 at 04:18:01PM -0400

Venkateshr@ami.com said:
> 	> 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?
> 
> 	We really cannot assume this. There are two cases 
> 		a. when a user app wants to receive some data, it allocates
> memory(using malloc) and waits for the hw to do zero-copy read. The kernel
> does not allocate physical page frames for the entire memory region
> allocated. We need to lock the memory (and locking is expensive due to
> costly TLB flushes) to do this
> 
> 		b. when a user app wants to send data, he fills the buffer
> and waits for the hw to transmit data, but under heavy physical memory
> pressure, the swapper might swap the pages we want to transmit. So we need
> to lock the memory to be 100% sure.

You're right, of course.  But I suspect that the fast path of
re-locking memory which is happily in core will go much faster
by removing the multi-processor TLB purge.  And it can't hurt,
unless I'm missing something.

		-- Pete

--- linux-2.4.4-stock/mm/mlock.c	Tue May  8 17:26:34 2001
+++ linux/mm/mlock.c	Tue May  8 17:24:13 2001
@@ -114,6 +114,10 @@
 	return 0;
 }
 
+/* implemented in mm/memory.c */
+extern int mlock_make_pages_present(struct vm_area_struct *vma,
+	unsigned long addr, unsigned long end);
+
 static int mlock_fixup(struct vm_area_struct * vma, 
 	unsigned long start, unsigned long end, unsigned int newflags)
 {
@@ -138,7 +142,7 @@
 		pages = (end - start) >> PAGE_SHIFT;
 		if (newflags & VM_LOCKED) {
 			pages = -pages;
-			make_pages_present(start, end);
+			mlock_make_pages_present(vma, start, end);
 		}
 		vma->vm_mm->locked_vm -= pages;
 	}

--- linux-2.4.4-stock/mm/memory.c	Tue May  8 17:25:36 2001
+++ linux/mm/memory.c	Tue May  8 17:24:40 2001
@@ -1438,3 +1438,80 @@
 	} while (addr < end);
 	return 0;
 }
+
+/*
+ * Specialized version of make_pages_present which does not require
+ * a multi-processor TLB purge for every page if nothing about the PTE
+ * was modified.
+ */
+int mlock_make_pages_present(struct vm_area_struct *vma,
+	unsigned long addr, unsigned long end)
+{
+	int ret, write;
+	struct mm_struct *mm = current->mm;
+
+	write = (vma->vm_flags & VM_WRITE) != 0;
+
+	/*
+	 * We need the page table lock to synchronize with kswapd
+	 * and the SMP-safe atomic PTE updates.
+	 */
+	spin_lock(&mm->page_table_lock);
+
+	ret = 0;
+	for (ret=0; !ret && addr < end; addr += PAGE_SIZE) {
+		pgd_t *pgd;
+		pmd_t *pmd;
+		pte_t *pte, entry;
+		int modified;
+
+		current->state = TASK_RUNNING;
+		pgd = pgd_offset(mm, addr);
+		pmd = pmd_alloc(mm, pgd, addr);
+		if (!pmd) {
+			ret = -1;
+			break;
+		}
+		pte = pte_alloc(mm, pmd, addr);
+		if (!pte) {
+			ret = -1;
+			break;
+		}
+		entry = *pte;
+		if (!pte_present(entry)) {
+			/*
+			 * If it truly wasn't present, we know that kswapd
+			 * and the PTE updates will not touch it later. So
+			 * drop the lock.
+			 */
+			if (pte_none(entry)) {
+				ret = do_no_page(mm, vma, addr, write, pte);
+				continue;
+			}
+			ret = do_swap_page(mm, vma, addr, pte,
+				pte_to_swp_entry(entry), write);
+			continue;
+		}
+
+		modified = 0;
+		if (write) {
+			if (!pte_write(entry)) {
+				ret = do_wp_page(mm, vma, addr, pte, entry);
+				continue;
+			}
+			if (!pte_dirty(entry)) {
+			    entry = pte_mkdirty(entry);
+			    modified = 1;
+			}
+		}
+		if (!pte_young(entry)) {
+			entry = pte_mkyoung(entry);
+			modified = 1;
+		}
+		if (modified)
+		    establish_pte(vma, addr, pte, entry);
+	}
+
+	spin_unlock(&mm->page_table_lock);
+	return ret;
+}

  parent reply	other threads:[~2001-05-08 21:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-08 20:18 Venkatesh Ramamurthy
2001-05-08 20:50 ` Alan Cox
2001-05-08 21:32 ` 'Pete Wyckoff' [this message]
     [not found] <034670D62D19D31180990090277A37B701811D72@mercury.corp.iready.com>
2001-05-08 13:04 ` Alan Cox
2001-05-08 20:00   ` 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=20010508173257.C15867@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®