From owner-freebsd-current@FreeBSD.ORG Sat Mar 10 11:37:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 736AC16A400 for ; Sat, 10 Mar 2007 11:37:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0921913C481 for ; Sat, 10 Mar 2007 11:37:08 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so1141562ika for ; Sat, 10 Mar 2007 03:37:08 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g+jFjGhkUwba/CCpwh+6+Za/Whw7BGcb7OEHENspq+9FRNdeuX73b57ET0+/tvQwa4UvayiUNBwzuE/Ae1rQ0qALHjFA0F1x+wjMgYOssHM5sz8Yk7KbRHysSDgjumkBuUCHkc3Hi/nKSraPyw1jZuhshV8o4Wsmsdrz9n+r754= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=imXyoeLiLpoSTn6iEP49UH2Bw5Mes96+mYyHpyJOV5fO4LwuXAShaXcbDgBCPnr9fV/zBhCH6GEU8Ihbwmv+LfORytMsE9bVo/scIrXAmB5jHIpk9XlK/LgUAtHyBHqpm/GxR1lrvcpHvk8nB5uOLDhUKazLCvQmumu4QsdxOF0= Received: by 10.70.32.10 with SMTP id f10mr5227630wxf.1173526627391; Sat, 10 Mar 2007 03:37:07 -0800 (PST) Received: by 10.100.191.11 with HTTP; Sat, 10 Mar 2007 03:37:07 -0800 (PST) Message-ID: <3bbf2fe10703100337y13224fc7jc22332b89628eb31@mail.gmail.com> Date: Sat, 10 Mar 2007 12:37:07 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Julian Elischer" In-Reply-To: <45F0D1F5.9010200@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45F0D1F5.9010200@elischer.org> X-Google-Sender-Auth: 15231db69b653ef8 Cc: FreeBSD Current Subject: Re: proc lock might become an sx lock? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 10 Mar 2007 11:37:09 -0000 2007/3/9, Julian Elischer : > currently the thread list in the process is protected by the sched lock. > for a process with a lot of threads this is probably not a good idea. > I experimented with making it protected by the proc loc, but the following > sort of thing happens a lot: > > sx_slock(&allproc_lock); > FOREACH_PROC_IN_SYSTEM(p) { > mtx_lock_spin(&sched_lock); > FOREACH_THREAD_IN_PROC(p, td) { > ... > } > mtx_unlock_spin(&sched_lock); > > Changing the protection of the thread list to use the proc lock would > replace the sched_lock with the proc lock, but..... > this has a problem.. the proc lock is a mutex and can therefore not be inside the > allproc_lock. > > and in fact you get: > > Trying to mount root from ufs:/dev/aacd0s1d > panic: blockable sleep lock (sleep mutex) process lock @ kern/sched_4bsd.c:383 > cpuid = 2 > KDB: enter: panic > [thread pid 48 tid 100054 ] > Stopped at kdb_enter+0x2b: nop > db> bt > Tracing pid 48 tid 100054 td 0xc5ff4a20 > kdb_enter(c06ce300) at kdb_enter+0x2b > panic(c06d3506,c06e7061,c06cd73b,c06cff47,17f,...) at panic+0x11c > witness_checkorder(c60a12c8,9,c06cff47,17f) at witness_checkorder+0xb8 > _mtx_lock_flags(c60a12c8,0,c06cff3e,17f,85,...) at _mtx_lock_flags+0x87 > schedcpu(e65a9d24,c0516f50,0,e65a9d38,c6259000,...) at schedcpu+0x80 > schedcpu_thread(0,e65a9d38) at schedcpu_thread+0x9 > > My reading of the man page is that making it an sx lock and locking it in > shared mode would be sufficient for this sort of thing (assuming we are not changing > the thread list) and would be just fine. > > I'm not very familiar with the implementation of sx locks in freeBSD so I'm just learning > about them. > > am I reading this right? and does anyone else have any thoughts on this? sx locks, mutexes and spin-lockes have very different low level behaviours, so you should avoid to replace one of them with one of another type. However, you can try to replace a mutex with a rwlock which use the same low-level interfaces. Attilio -- Peace can only be achieved by understanding - A. Einstein