From owner-svn-src-projects@FreeBSD.ORG Fri May 13 13:50:48 2011 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2B9106566C; Fri, 13 May 2011 13:50:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 127FE8FC17; Fri, 13 May 2011 13:50:47 +0000 (UTC) Received: by gwb15 with SMTP id 15so1100851gwb.13 for ; Fri, 13 May 2011 06:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t663UAZ+BlHI1V/3K8bp+otgPGn7m60yUitsEvrPstk=; b=JlEPYbGrqw4TMGx+zsZvCBJ95MJeiPOsIDR5CE95DW7dTliqmarCAHfJfWw5/7dsuc u7phs2gsV7e77eFopbVBw3uwvow66pzbDxgEsYFM+mTgbGL/d9j7yBHa1tTEafNiBBDc 1vjbWdWF0s74ZfFP81gD2MQiwN/UuMiybtIcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dQeY6p2c/aFv4vZ0Kr0UNJWbW/D4OXfNSFpDoIj2pfqQS2uTXdVsj5ukx4uu9FIrkg ScO3gXw1hSlN9BQGT1NJJ/MmtgM4x41WYN1MND/rR5qKNqvNrVDWdc93FXkwoU058/OF CixZzQH0UEbXUwOZ5/g+meplQCj/Fu9oHB14k= MIME-Version: 1.0 Received: by 10.236.195.99 with SMTP id o63mr1361986yhn.238.1305294647325; Fri, 13 May 2011 06:50:47 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.111.33 with HTTP; Fri, 13 May 2011 06:50:47 -0700 (PDT) In-Reply-To: <20110513221936.X1161@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110513221936.X1161@besplex.bde.org> Date: Fri, 13 May 2011 15:50:47 +0200 X-Google-Sender-Auth: A648GAu_Ysb3poY-0XY1eWrjy_w Message-ID: From: Attilio Rao To: Bruce Evans Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-projects@freebsd.org, Artem Belevich , src-committers@freebsd.org, Warner Losh , Oleksandr Tymoshenko Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 13:50:48 -0000 2011/5/13 Bruce Evans : > On Thu, 12 May 2011, Attilio Rao wrote: > >> 2011/5/12 Artem Belevich : > >>> Could you post definition of cpuset_t ? >>> >>> It's possible that compiler was actually correct. For instance, >>> compiler would be right to complain if cpuset_t is a packed structure, >>> even if that structure is made of a single uint32_t field. >> >> It doesn't do the atomic of =C2=A0cpuset_t, it does atomic of members of >> cpuset_t which are actually long. >> For example: >> #define CPU_OR_ATOMIC(d, s) do { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ >> =C2=A0 =C2=A0 =C2=A0 __size_t __i; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 \ >> =C2=A0 =C2=A0 =C2=A0 for (__i =3D 0; __i < _NCPUWORDS; __i++) =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 atomic_set_long(&(d)->_= _bits[__i], =C2=A0 =C2=A0 =C2=A0\ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (s)->__bi= ts[__i]); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ >> } while (0) > > BTW, how can any code like this (operating on an array) be atomic enough? (Replying to similar questions once for all, because it is not the first ti= me): Protection must not be handled here, but from the callers, which know the context. Right now we have something like (for a typical, shared, cpumask_t function= s): volatile cpumask_t stoppedcpus; void f() { cpumask_t c; ... c =3D stoppedcpus; (operations on c) Whatever happens stoppedcpus may change just after read or write, then it means we use stoppedcpus and other mask objects unlocking, we just bear with races. That works right now, because we really don't preview a dynamic scheme for CPUs. They are setup at system boot and will remain like that pretty much forever. The per-cpu stuff also, is read only. The pm_active objects are protected by VM locks. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein