Date: Tue, 29 Jun 2010 14:25:11 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: neelnatu@gmail.com Cc: freebsd-mips@freebsd.org Subject: Re: Merging 64 bit changes to -HEAD Message-ID: <20100629.142511.47726460528861958.imp@bsdimp.com> In-Reply-To: <AANLkTikIMYAfntzNC60L7ZXZm2lCavtDhxCsmyiRrfw0@mail.gmail.com> References: <AANLkTilQIqF4FCfgLdVcKdcsAUVjCmr89Lu0TEXUFdYN@mail.gmail.com> <20100629.112421.25793712605171655.imp@bsdimp.com> <AANLkTikIMYAfntzNC60L7ZXZm2lCavtDhxCsmyiRrfw0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <AANLkTikIMYAfntzNC60L7ZXZm2lCavtDhxCsmyiRrfw0@mail.gmail.c=
om>
Neel Natu <neelnatu@gmail.com> writes:
: Hi,
: =
: On Tue, Jun 29, 2010 at 10:24 AM, M. Warner Losh <imp@bsdimp.com> wro=
te:
: > In message: <AANLkTilQIqF4FCfgLdVcKdcsAUVjCmr89Lu0TEXUFdYN@mail.gma=
il.com>
: > =A0 =A0 =A0 =A0 =A0 =A0"Jayachandran C." <c.jayachandran@gmail.com>=
writes:
: > : On Tue, Jun 29, 2010 at 2:28 AM, Luiz Otavio O Souza <lists.br@gm=
ail.com> wrote:
: > : >> Thanks for the the update. Looks like pmap_map for kernel is f=
ailing,
: > : >> may be the new tlb_update code causes this. =A0Can you apply t=
he
: > : >> attached patch and see if the problem still persists, it repla=
ces the
: > : >> new tlb_update code with the older version.
: > : >>
: > : >> Obviously not a fix, but if we can narrow it down to this func=
tion,
: > : >> fixing will be easier.
: > : >>
: > : >> JC.
: > : >> <try.diff>
: > : >
: > : > JC,
: > : >
: > : > This fix the problem ! Thanks ! Now, at least, you know where t=
o look :)
: > :
: > : The new tlb_update does not seem to update the tlb entry if the t=
lbp
: > : fails. =A0Here's a patch that should make the new function behave=
like
: > : the older one. =A0The patch is in attached file 'tlb-update.diff'=
.=
: > :
: > : If that does not work, I'm not sure what the issue is. =A0You cou=
ld also
: > : try try the nop-change.diff attached. It tries to switch the ssno=
p
: > : used for delay in the new code with 'nop' which was used by the o=
ld
: > : code.
: >
: > ssnop is a mips32r2/mips64r2 addition. =A0We likely need to get sma=
rter
: > about the nop stuff, based on the CPU we configure. =A0I can't reca=
ll if
: > the Atheros is misp32 or mips32r2. =A0IIRC, the idt RC32434 is mips=
32,
: > as is the adm5120...
: >
: =
: It seems that ssnop should be identical to nop on non-superscalar pro=
cessors.
: =
: Here is the snippet from vol2 of the mips64 architecture manual.
: =
: <snip>
: Format:
: MIPS32
: SSNOP
: Purpose:
: Break superscalar issue on a superscalar processor.
: Description:
: SSNOP is the assembly idiom used to denote superscalar no operation.
: The actual instruction is interpreted by the
: hardware as SLL r0, r0, 1.
: This instruction alters the instruction issue behavior on a
: superscalar processor by forcing the SSNOP instruction to
: single-issue. The processor must then end the current instruction
: issue between the instruction previous to the SSNOP
: and the SSNOP. The SSNOP then issues alone in the next issue slot.
: On a single-issue processor, this instruction is a NOP that takes an =
issue slot.
: </snip>
: =
: It may lead to less efficient code on multiple issue processors but
: replacing a nop with an ssnop should be always be safe, right?
You're right. For processors that don't support ssnop, it is
identical to nop. But a single ssnop may not be sufficient on all
processors. But, as a practical matter, I think that 4 ssnops is the
same as 4 nops and sufficient for tlb hazards.
However, I was confusing ssnop with ehb (and jump variants). ehb in
MIPS{32,64}R2 processors so that a single instruction will delay the
right amount to prevent any CP0 and other hazards. I'd argue we
should use these instructions on R2 processors, since they are more
efficient than guessing the right number of nops. Shorter too :)
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100629.142511.47726460528861958.imp>