All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <brian.foster@innova-card.com>
To: David Daney <ddaney@caviumnetworks.com>
Cc: "Kevin D. Kissell" <kevink@paralogos.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH 1/2] MIPS: Preliminary vdso.
Date: Mon, 27 Apr 2009 09:19:00 +0200	[thread overview]
Message-ID: <200904270919.00761.brian.foster@innova-card.com> (raw)
In-Reply-To: <49F1DB1B.2060209@caviumnetworks.com>

On Friday 24 April 2009 17:30:35 David Daney wrote:
> Kevin D. Kissell wrote:
> > Brian Foster wrote:
> >> On Wednesday 22 April 2009 20:01:44 David Daney wrote:
> >>> Kevin D. Kissell wrote:
> >>>> David Daney wrote:
> >>>>> This is a preliminary patch to add a vdso to all user processes.
> >>>>>[ ... ]
> >>>> Note that for FPU-less CPUs, the kernel FP emulator also uses a user
> >>>> stack trampoline to execute instructions in the delay slots of emulated
> >>>> FP branches.  [ ... ]
> >>
> >>    As David says, this is a Very Ugly Problem.  Each FP trampoline
> >>   is effectively per-(runtime-)instance per-thread [ ... ]
> > 
> > I haven't reviewed David's code in detail, but from his description, I 
> > thought that there was a vdso page per task/thread.  If there's only one 
> > per processor, then, yes, that poses a challenge to porting the FPU 
> > emulation code to use it, since, as you observe, the instruction 
> > sequence to be executed may differ for each delay slot emulation.  It 
> > should still be possible, though.  [ ... ]
> 
> Kevin is right, this is ugly.
> 
> My current plan is to map an anonymous page with execute permission for 
> each vma (process) and place all FP trampolines there.  Each thread that 
> needs a trampoline will allocate a piece of this page and write the 
> trampoline.  We can arrange it so that the only way a thread can exit 
> the trampoline is by taking some sort of fault (currently this is true 
> for the normal case), or exiting.

David,

   The above is the bit which has always stumped me.
  Having a per-process(or similar) page for the FP
  trampoline(s) is the “obvious” approach, but what
  has had me going around in circles is how to know
  when an allocated slot/trampoline can be freed.
  As you imply, in the normal case, it seems trivial.
  It's the not-normal cases which aren't clear (or at
  least aren't clear to me!).

   You say (EMPHASIS added) “We can arrange it so
  that the ONLY way a thread can exit the trampoline
  is by taking some sort of fault ... or exiting”,
  which if true, could solve the issue.  Could you
  elucidate on this point, please?

  Thanks for your time, effort, and patience.
cheers!
	-blf-

>                                    Then we free the trampoline for other 
> threads to use.  If all the slots in the trampoline page are in use, a 
> thread would block until there is a free one, rarely, if ever would this 
> happen.
>[ ... ]

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

  reply	other threads:[~2009-04-27  7:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-21 21:30 [PATCH 0/2] MIPS: Move signal return trampolines off the stack David Daney
2009-04-21 21:33 ` [PATCH 1/2] MIPS: Preliminary vdso David Daney
2009-04-22  5:24   ` Shane McDonald
2009-04-22 15:18     ` David Daney
2009-04-22  9:35   ` Kevin D. Kissell
2009-04-22 18:01     ` David Daney
2009-04-24  7:20       ` Brian Foster
2009-04-24  7:50         ` Kevin D. Kissell
2009-04-24 15:30           ` David Daney
2009-04-27  7:19             ` Brian Foster [this message]
2009-04-27 12:51               ` Kevin D. Kissell
2009-04-27 15:54                 ` David Daney
2009-04-27 17:27                   ` Kevin D. Kissell
2009-04-27 18:26                     ` David Daney
2009-04-22 17:50   ` David VomLehn
2009-04-22 18:05     ` David Daney
2009-04-22 18:28       ` David VomLehn
2009-04-21 21:33 ` [PATCH 2/2] MIPS: Move signal trampolines off of the stack David Daney
2009-04-22 17:57   ` David VomLehn
2009-04-22 18:04 ` [PATCH 0/2] MIPS: Move signal return trampolines off " David VomLehn
2009-04-22 18:13   ` David Daney
2009-04-22 18:31     ` David VomLehn

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=200904270919.00761.brian.foster@innova-card.com \
    --to=brian.foster@innova-card.com \
    --cc=ddaney@caviumnetworks.com \
    --cc=kevink@paralogos.com \
    --cc=linux-mips@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.