From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g6QJYpRw019443 for ; Fri, 26 Jul 2002 12:34:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g6QJYpWu019442 for linux-mips-outgoing; Fri, 26 Jul 2002 12:34:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g6QJYiRw019433 for ; Fri, 26 Jul 2002 12:34:44 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g6QJZCXb007431; Fri, 26 Jul 2002 12:35:12 -0700 (PDT) Received: from menelaus.mips.com (menelaus [192.168.65.223]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA29089; Fri, 26 Jul 2002 12:35:13 -0700 (PDT) Received: from mips.com (localhost [127.0.0.1]) by menelaus.mips.com (8.9.3/8.9.0) with ESMTP id MAA05218; Fri, 26 Jul 2002 12:35:13 -0700 (PDT) Message-ID: <3D41A471.F3666A7@mips.com> Date: Fri, 26 Jul 2002 12:35:13 -0700 From: "Kevin D. Kissell" Organization: MIPS Technologies Inc. X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Johannes Stezenbach , Jun Sun , linux-mips@oss.sgi.com Subject: Re: LL/SC benchmarking [was: Mipsel libc with LL/SC online anywhere?] References: <00ce01c229a4$a7d4ed40$10eca8c0@grendel> <20020719123828.GA5521@convergence.de> <20020725162539.GA8804@convergence.de> <3D40302F.40806@mvista.com> <20020725184519.GB9302@convergence.de> <3D407254.233BE0DB@mips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Kevin D. Kissell" wrote: > The prudent thing to do would be to load the MAGIC_COOKIE > value explicitly into k1 on the way out of general exception > service. Fortunately, it looks to me as if at least half > of the overhead of this operation (LUI/ORI) can be concealed > in branch/jump delay slots that are currently going unfilled. I was distracted in the middle of that reply and got confused. The MAGIC_COOKIE needs only to be destroyed, which can be done in a single instruction. The 100% safe approach would be to insert a "move k1,zero" instruction before all ERETs, including those generated by the RESTORE_ALL_AND_RET macro expansion, but it should faster, if very slightly larger and somewhat more burdensome for maintenence, to plant those instructions in branch delay slots just "upstream" from the context restore. I'm working on the code a bit and may be able to propose (if not test :-) a patch along these lines, but in looking at entry.S, I note something a bit disturbing: There's a lot of code in there that allows the assembler to schedule the instructions, but which also contains SSNOPs to force timing. Isn't that a bit dangerous? Unless it is specified that the assembler will refuse to reschedule SSNOPs, I think those sequences need to be bracketed with .noreorder directives. That would also allow k1 destructors to be placed explicitly in the delay slots, rather than assuming that they will be put there by the assembler. Regards, Kevin K.