From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 02:22:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 423D5DBD for ; Sat, 24 May 2014 02:22:33 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF64C2D7A for ; Sat, 24 May 2014 02:22:32 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id u57so5611851wes.4 for ; Fri, 23 May 2014 19:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TtbC+l8IG0eVrsqloZNyd9sjzdV55cg8zMi9mQrDCLc=; b=Mm3ey7pzr1SJt11esvIXd16BU+vBka05YXQBKPJ3rKa+pSF+4wyZspKgzTeo2q9ETH MouDSebwbn6sJad/Z8I+NLdkTsaTMZN7JBoCnzq/o5MQi4iCyEZfr9dQN+nTYJrLkhWx AdAT0Ml79IYlOz+NYT45YwZonbxCy46u2bcHMe7eQRNcqU5Mjr9XcgAwIvw3DKJcks6S LTpNyUNVq5rYxkMtjcqYP69Tt4beENVkP7tkEC53gCk8TZGp/LN7JrrjxKPgi2N3xMB+ ou5hnSfZ0t93vnIDWtTbkbSQ2NjYPT+lLk5m4cGigSK/UAIcaPbPmy4Ti+hnMlzLTnHw Denw== MIME-Version: 1.0 X-Received: by 10.180.14.72 with SMTP id n8mr7021822wic.53.1400898151113; Fri, 23 May 2014 19:22:31 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.168.130 with HTTP; Fri, 23 May 2014 19:22:31 -0700 (PDT) In-Reply-To: <537FFE81.2080504@tysdomain.com> References: <537FFE81.2080504@tysdomain.com> Date: Fri, 23 May 2014 20:22:31 -0600 X-Google-Sender-Auth: KB9MpMLQLL13Zt7FVaKDL9a6T64 Message-ID: Subject: Re: no SSE in kernel build? From: Alan Somers To: tyler@tysdomain.com Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 02:22:33 -0000 On Fri, May 23, 2014 at 8:05 PM, Littlefield, Tyler wrote: > Hello all: > I had a quick question I was hoping someone could explain for me. I was > looking at some of the kernel source, just trying to familiarize myself with > it. I notice that SSE, MMX and other such instruction sets are explicitly > disabled during kernel compilation--is there any particular reason why? I'm > sure it's pretty obvious, but my knowledge of kernel workings is pretty > limited. I've seen functions like memset/memcpy that make use of SSE and are > incredibly fast; perhaps this could be useful on architectures that support > it? Because the SSE registers would rarely be useful in kernel code, they are explicitly excluded from he system call ABI. That is, the kernel does not save them to the stack on interrupts or system calls. Hence, the kernel can't use them at all. But select parts of the kernel can use them thanks to the fpu_kern_enter/fpu_kern_leave API. More details at this link: http://lists.freebsd.org/pipermail/freebsd-arch/2010-March/010005.html > > Finally, I'm interested in doing some performance work on the > kernel--perhaps to help out somewhere. Is there anything at the kernel level > a beginner could help out with? Where else might my help be useful? I know > -some-, as I've worked a bit on a barebones OS, but I'm no means a kernel > hacker. > Thanks, I think that most of the kernel's performance problems would be hard stuff for a beginner. David Xu suggested that devd(8) could be modified to use kqueue. Not in the kernel, I know, but it would be easy. Another thing you could do would be to apply the counters(9) API more thoroughly through the kernel. It's a high performance API for statistical counters that minimizes lock contention and cache coherency conflicts. It's also fairly new, so I bet there are places that could be using but aren't. -Alan > > -- > Take care, > Ty > http://tds-solutions.net > He that will not reason is a bigot; he that cannot reason is a fool; he that > dares not reason is a slave.