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(¤t->mm->mmap_sem);
> + n = get_user_pages(current, current->mm, start_page, num_pages, 1, 1,
> + p, NULL);
> + up_read(¤t->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(¤t->mm->mmap_sem);
> + n = get_user_pages(current, current->mm, start_page, 1, 1, 1, p, &vm);
> + up_read(¤t->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().
next prev 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