mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Roland Dreier <rolandd@cisco.com>
Cc: linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [PATCH 07/13]  [RFC] ipath core misc files
Date: Sat, 17 Dec 2005 12:38:50 -0800	[thread overview]
Message-ID: <20051217123850.aa6cfd53.akpm@osdl.org> (raw)
In-Reply-To: <200512161548.3fqe3fMerrheBMdX@cisco.com>

Roland Dreier <rolandd@cisco.com> wrote:
>
> ...
> +/*
> + * This isn't perfect, but it's close enough for timing work. We want this
> + * to work on systems where the cycle counter isn't the same as the clock
> + * frequency.  The one msec spin is OK, since we execute this only once
> + * when first loaded.  We don't use CURRENT_TIME because on some systems
> + * it only has jiffy resolution; we just assume udelay is well calibrated
> + * and that we aren't likely to be rescheduled.  Do it multiple times,
> + * with a yield in between, to try to make sure we get the "true minimum"
> + * value.
> + * _ipath_pico_per_cycle isn't going to lead to completely accurate
> + * conversions from timestamps to nanoseconds, but it's close enough
> + * for our purposes, which is mainly to allow people to show events with
> + * nsecs or usecs if desired, rather than cycles.
> + */
> +void ipath_init_picotime(void)
> +{
> +	int i;
> +	u_int64_t ts, te, delta = -1ULL;
> +
> +	for (i = 0; i < 5; i++) {
> +		ts = get_cycles();
> +		udelay(250);
> +		te = get_cycles();
> +		if ((te - ts) < delta)
> +			delta = te - ts;
> +		yield();
> +	}
> +	_ipath_pico_per_cycle = 250000000 / delta;
> +}

hm, I hope this is debug code which is going away.  If not, we should take
a look at what it's trying to do here.


> +/*
> + * Our version of the kernel mlock function.  This function is no longer
> + * exposed, so we need to do it ourselves.  It takes a given start page
> + * (page aligned user virtual address) and pins it and the following specified
> + * number of pages.
> + * For now, num_pages is always 1, but that will probably change at some
> + * point (because caller is doing expected sends on a single virtually
> + * contiguous buffer, so we can do all pages at once).
> + */
> +int ipath_mlock(unsigned long start_page, size_t num_pages, struct page **p)
> +{
> +	int n;
> +
> +	_IPATH_VDBG("pin %lx pages from vaddr %lx\n", num_pages, start_page);
> +	down_read(&current->mm->mmap_sem);
> +	n = get_user_pages(current, current->mm, start_page, num_pages, 1, 1,
> +			   p, NULL);
> +	up_read(&current->mm->mmap_sem);
> +	if (n != num_pages) {
> +		_IPATH_INFO
> +		    ("get_user_pages (0x%lx pages starting at 0x%lx failed with %d\n",
> +		     num_pages, start_page, n);
> +		if (n < 0)	/* it's an errno */
> +			return n;
> +		return -ENOMEM;	/* no way to know actual error */
> +	}
> +
> +	return 0;
> +}

OK.  It's perhaps not a very well named function.

> +/*
> + * this is similar to ipath_mlock, but it's always one page, and we mark
> + * the page as locked for i/o, and shared.  This is used for the user process
> + * page that contains the destination address for the rcvhdrq tail update,
> + * so we need to have the vma.  If we don't do this, the page can be taken
> + * away from us on fork, even if the child never touches it, and then
> + * the user process never sees the tail register updates.
> + */
> +int ipath_mlock_nocopy(unsigned long start_page, struct page **p)
> +{
> +	int n;
> +	struct vm_area_struct *vm = NULL;
> +
> +	down_read(&current->mm->mmap_sem);
> +	n = get_user_pages(current, current->mm, start_page, 1, 1, 1, p, &vm);
> +	up_read(&current->mm->mmap_sem);
> +	if (n != 1) {
> +		_IPATH_INFO("get_user_pages for 0x%lx failed with %d\n",
> +			    start_page, n);
> +		if (n < 0)	/* it's an errno */
> +			return n;
> +		return -ENOMEM;	/* no way to know actual error */
> +	}
> +	vm->vm_flags |= VM_SHM | VM_LOCKED;
> +
> +	return 0;
> +}

I don't think we want to be setting the user's VMA's vm_flags in this
manner.  This is purely to retain the physical page across fork?

> +/*
> + * Our version of the kernel munlock function.  This function is no longer
> + * exposed, so we need to do it ourselves.  It unpins the start page
> + * (a page aligned full user virtual address, not a page number)
> + * and pins it and the following specified number of pages.
> + */
> +int ipath_munlock(size_t num_pages, struct page **p)
> +{
> +	int i;
> +
> +	for (i = 0; i < num_pages; i++) {
> +		_IPATH_MMDBG("%u/%lu put_page %p\n", i, num_pages, p[i]);
> +		SetPageDirty(p[i]);
> +		put_page(p[i]);
> +	}
> +	return 0;
> +}

Nope, SetPageDirty() doesn't tell the VM that the page is dirty - it'll
never get written out.  Use set_page_dirty_lock().



  parent reply	other threads:[~2005-12-17 20:39 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20051031150618.627779f1.akpm@osdl.org>
2005-12-16 23:48 ` [PATCH 00/13] [RFC] IB: PathScale InfiniPath driver Roland Dreier
2005-12-16 23:48   ` [PATCH 01/13] [RFC] ipath basic headers Roland Dreier
2005-12-16 23:48     ` [PATCH 02/13] [RFC] ipath debug header Roland Dreier
2005-12-16 23:48       ` [PATCH 03/13] [RFC] ipath copy routines Roland Dreier
2005-12-16 23:48         ` [PATCH 04/13] [RFC] ipath LLD core, part 1 Roland Dreier
2005-12-16 23:48           ` [PATCH 05/13] [RFC] ipath LLD core, part 2 Roland Dreier
2005-12-16 23:48             ` [PATCH 06/13] [RFC] ipath LLD core, part 3 Roland Dreier
2005-12-16 23:48               ` [PATCH 07/13] [RFC] ipath core misc files Roland Dreier
2005-12-16 23:48                 ` [PATCH 08/13] [RFC] ipath core last bit Roland Dreier
2005-12-16 23:48                   ` [PATCH 09/13] [RFC] ipath IB driver headers Roland Dreier
2005-12-16 23:48                     ` [PATCH 10/13] [RFC] ipath verbs, part 1 Roland Dreier
2005-12-16 23:48                       ` [PATCH 11/13] [RFC] ipath verbs, part 2 Roland Dreier
2005-12-16 23:48                         ` [PATCH 12/13] [RFC] ipath verbs MAD handling Roland Dreier
2005-12-16 23:48                           ` [PATCH 13/13] [RFC] ipath Kconfig and Makefile Roland Dreier
2005-12-17 21:52                             ` Adrian Bunk
2005-12-17 22:54                               ` [openib-general] " Robert Walsh
2005-12-17 23:55                                 ` Adrian Bunk
2005-12-18  1:17                                   ` Robert Walsh
2005-12-18  0:27                                 ` Alan Cox
2005-12-18 19:23                             ` Sam Ravnborg
2005-12-20  0:32                               ` [openib-general] " Robert Walsh
2005-12-26  2:49                               ` Roland Dreier
2005-12-18 19:59                       ` [PATCH 10/13] [RFC] ipath verbs, part 1 Paul E. McKenney
2005-12-18 20:05                         ` [openib-general] " Robert Walsh
2005-12-19 20:50                         ` Ralph Campbell
2005-12-17 20:38                   ` [PATCH 08/13] [RFC] ipath core last bit Andrew Morton
2005-12-21  0:00                     ` Robert Walsh
2005-12-17 20:38                 ` Andrew Morton [this message]
2005-12-17 21:29                   ` [PATCH 07/13] [RFC] ipath core misc files Robert Walsh
2005-12-17 21:33                   ` Robert Walsh
2005-12-18  3:10                     ` Andrew Morton
2005-12-18  3:13                       ` Robert Walsh
2005-12-17 20:38           ` [PATCH 04/13] [RFC] ipath LLD core, part 1 Andrew Morton
2005-12-17 21:34             ` Robert Walsh
2005-12-17 12:38         ` [PATCH 03/13] [RFC] ipath copy routines Pekka Enberg
2005-12-17 21:38           ` Robert Walsh
2005-12-17 13:16         ` Christoph Hellwig
2005-12-17 20:38         ` Andrew Morton
2005-12-17 22:40           ` Robert Walsh
2005-12-18  3:19             ` Andrew Morton
2005-12-18  3:35               ` Adrian Bunk
2005-12-18  5:33               ` Robert Walsh
2005-12-18  9:33               ` David S. Miller
2005-12-18 19:52                 ` Robert Walsh
2005-12-18  3:27             ` Andi Kleen
2005-12-18  5:36               ` Robert Walsh
2005-12-18  5:41                 ` Andi Kleen
2005-12-18 13:25               ` Alan Cox
2005-12-17 12:33     ` [PATCH 01/13] [RFC] ipath basic headers Pekka Enberg
2005-12-17 21:55       ` Robert Walsh
2005-12-17 13:14     ` Christoph Hellwig
2005-12-17 21:51       ` Eric W. Biederman
2005-12-18  3:25         ` Andi Kleen
2005-12-18 15:02           ` Eric W. Biederman
2005-12-17 22:19       ` Robert Walsh
2005-12-17 22:25         ` Arjan van de Ven
2005-12-17 22:47           ` Robert Walsh
2005-12-17 20:38     ` Andrew Morton
2005-12-17 22:39       ` Robert Walsh
2005-12-18  3:14         ` Andrew Morton
2005-12-20  1:43       ` Robert Walsh
2005-12-17 13:16   ` [PATCH 00/13] [RFC] IB: PathScale InfiniPath driver Christoph Hellwig
2005-12-17 15:51     ` Roland Dreier

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=20051217123850.aa6cfd53.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openib-general@openib.org \
    --cc=rolandd@cisco.com \
    /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

Powered by JetHome