From owner-svn-src-all@FreeBSD.ORG Tue Jan 26 20:15:30 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E22EA106568D; Tue, 26 Jan 2010 20:15:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC2F8FC1B; Tue, 26 Jan 2010 20:15:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0QK8gug076235; Tue, 26 Jan 2010 13:08:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 26 Jan 2010 13:09:32 -0700 (MST) Message-Id: <20100126.130932.722022410132669562.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <3bbf2fe11001260058i65604619l664bd0e49c1dbbd@mail.gmail.com> <3bbf2fe11001260339u7a694069m6a2bb7e18b2c546a@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, jhb@freebsd.org, svn-src-all@freebsd.org, attilio@freebsd.org, marcel@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r202889 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:15:30 -0000 In message: Marcel Moolenaar writes: : : On Jan 26, 2010, at 3:39 AM, Attilio Rao wrote: : >>> : >>> Does this affect the various #ifdef's for handling the third argument to : >>> cpu_switch()? E.g. does 4BSD need to spin if td_lock is &blocked_lock? : >>> : > : > I think that ia64 is broken on that regard because it does use simple : > operation while it should use correct atomic and memory barriers : > (CC'ed marcel@ for that). : : Ok, so cpu_switch() handles the 3rd argument (the mutex) only : when SCHED_ULE and SMP are defined, even on i386. Maybe it's : just me, but if SCHED_4BSD now also uses the 3rd argument then : all implementations of cpu_switch() are broken, right? No. The current implementations always STORE the argument. One only loops if newthread->td_lock == blocked_lock. which is something else. That was part of my initial confusion as well... : Maybe what is in order right now is a description (using pseudo : code if you like) of what exactly needs to happen with the 3rd : argument, when and how (i.e. what must be atomic and what does : not have to be atomic). I believe the proper pseudo code should be: cpu_switch(struct thread *old, struct thread *new, struct mutext *mtx) { /* Save the registers to the pcb */ old->td_lock = mtx; #if defined(SMP) && defined(SCHED_ULE) /* s/long/int/ if sizeof(long) != sizeof(void *) */ /* as we have no 'void *' version of the atomics */ while (atomic_load_acq_long(&new->td_lock) == (long)&blocked_lock) continue; #endif /* Switch to new context */ } although the #ifdef might not actually be strictly necessary (eg, 4BSD doesn't migrate threads like ULE does, so you don't hit the case of having to wait for the new thread to become unblocked). At least that's the impression I have after reading Atillio's email on this topic. I also think that we should have that code somewhere for reference. When I was bringing up the MIPS code from the 6.1 base to -current, the third argument made no sense to me at all, so I didn't implement it at all. Someone (gonzo@?) tried to implement it, but it was found recently to have been implemented wrong. That's been fixed now, and as part of fixing it, I started asking questions... : I can deal with ia64 and powerpc once I know for certain what : exactly needs to happen, because it seems to me that I can't : really look at the i386 implementation and infer what needs to : happen. I think that the only difference between what mips has now and what is needed is that mips implements the while loop as approximately: while ((volatile)new->td_lock == &blocked_lock) continue; so I need to figure out the right memory barrier assembler instruction to make this right. I think sync might be it for mips, but maybe it is sync or some other processor dependent instruction (Cavium has special instructions for things like this with more tailored semantics, for example). Warner