[Top] [All Lists]

Re: [PATCH 1/2] MIPS: Preliminary vdso.

To: David Daney <>
Subject: Re: [PATCH 1/2] MIPS: Preliminary vdso.
From: Brian Foster <>
Date: Mon, 27 Apr 2009 09:19:00 +0200
Cc: "Kevin D. Kissell" <>,
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:sender:from:reply-to:to :subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; bh=bUEt2hoeZibzPa+g196oZ0b3blL7JgU0WW4oHHGgmL4=; b=TJ1YfXokMi8XmALtjxwcgUXY7Hh+0aB3R0fkV8szjHbMEhbBS95x+XCIV3yeRtmZju 3PhbDolw9HUtyuWaY62c4RMVfg9bXlkLoaH4RkCe4F2u79basxQc/TBm7Cabxu/N0Yv1 Fi6C0b7thv9Ds5bCCac2g3RuDZNoEbS8L7Iag=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:from:reply-to:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=oyTK2B0dS90kldcN3ICvv/MF9/Bgu1yjiuEhVswidXB14egAaSzomu4VPa1YpX5agx HpRDoBCsj9s1s9UFmzpDiH4Si/gyKdcomtjlv0dp0T/a97+fzamGkplYz91XGKGCIAXR ZE+HacC6puuh8c4I0eQYYS0iUCwq+SN49EVrc=
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
Reply-to: Brian Foster <>
User-agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; x86_64; ; )
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.


   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.

>                                    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.” |

<Prev in Thread] Current Thread [Next in Thread>