From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 22:28:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BEE3F78F; Thu, 21 Feb 2013 22:28:34 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id 72A2B157; Thu, 21 Feb 2013 22:28:34 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id w7so20655qeb.23 for ; Thu, 21 Feb 2013 14:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z2YLI6yHbUQcs6EYr0A1tgdbSbBJMUOqR1Pjl7Z0xdI=; b=eVVBqslaXXBiqo78kf0nqYuI/9JJKjd30pyM41ir9Q44DbUK1YRKJkoVBzcwS9JjMS N7Yuivo/tBdImGImZbNKbr5WToAD2qCZm18r7la/ckaA57dCqR9WdnhyJoseVBKrp1nF k85CGk3bNfpFzLEdQCa4AlHd9TIxYIa8jIPqTHHLToco3CWY4bEZmxsaPQ3qQ896PvpB H3HlTaGLSjEUIvLcM/52n4HxAOBRSt3KExUmv72LtX94SxV6/ApGqtymBJGLnfR8H54q 2qvHlWyHtDCAQXVD8Ag4ykSX8UuxJLGovPg4/RlvnyqLXRoRFpGzLTIyPFwnsbm0SDCd nI3w== MIME-Version: 1.0 X-Received: by 10.49.107.4 with SMTP id gy4mr13180947qeb.63.1361485707986; Thu, 21 Feb 2013 14:28:27 -0800 (PST) Received: by 10.49.121.198 with HTTP; Thu, 21 Feb 2013 14:28:27 -0800 (PST) In-Reply-To: <201302211043.49906.jhb@freebsd.org> References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> Date: Thu, 21 Feb 2013 23:28:27 +0100 Message-ID: Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:28:34 -0000 On Thu, Feb 21, 2013 at 4:43 PM, John Baldwin wrote: >> > curthread is a bit magic. :) If you perform a context switch during an >> > interrupt (which will change 'curthread') you also change your register state. >> > When you resume, the register state is also restored. This means that while >> > something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' >> > never is. However, it is true that actually reading curthread has to be >> > atomic. If your read of curthread looks like: >> > >> > mov , r0 >> > add , r0 >> > ld r0, r1 >> > >> > Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' >> > (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that >> > pc_curthread is the first thing in 'struct pcpu' (and always will be, you could >> > add a CTASSERT to future-proof). In that case, you can remove the 'add' >> > instruction and instead just do: >> > >> > ld , r1 >> > >> > which is fine. >> >> Just for the record. There are three extra (coprocessor) registers per >> a core in arm11mpcore (armv6k). Unfortunately only one is Privileged. >> The other ones are respectively User Read only and User Read Write. >> For now, we are using the Privileged one to store pcpu pointer >> (curthread is correctly set during each context switch). Thus, using a >> coprocessor register means that reading of curthread is not a single >> instruction implementation now. After we figured out the curthread >> issue in SMP case, using a fixed (processor) register for pcpu is an >> option. Meanwhile, we disable interrupts before reading of curthread >> and enable them after. The same is done for other PCPU stuff. For now >> we have not stable system enough for profiling, however, when it will >> be, it would be interesting to learn how various implementations of >> curthread reading impact system performance. > > curthread is read _a lot_, so I would expect this to hurt. What we did on > Alpha was to use a fixed register for pcpu access, but we used the equivalent > of a coprocessor register to also store the value so we could set that fixed > register on entry to the kernel (userland was free to use the register for > its own purposes). Interesting solution. Thanks. Svata