From owner-freebsd-current@FreeBSD.ORG Tue Jan 19 04:34:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F5BF1065670; Tue, 19 Jan 2010 04:34:59 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id D71838FC1A; Tue, 19 Jan 2010 04:34:58 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id o0J4YvvF025133; Tue, 19 Jan 2010 13:34:57 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id o0J4Yxg12598; Tue, 19 Jan 2010 13:34:59 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/somla2) id o0J4YvOL009134; Tue, 19 Jan 2010 13:34:57 +0900 (JST) Received: from localhost by somla2.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id o0J4Yulk009092; Tue, 19 Jan 2010 13:34:56 +0900 (JST) Date: Tue, 19 Jan 2010 13:34:55 +0900 (JST) Message-Id: <20100119.133455.123339447290605132.okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org, jroberson@jroberson.net From: Kohji Okuno In-Reply-To: <20100118.160456.519459540419521301.okuno.kohji@jp.panasonic.com> References: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> <20100118.155352.59640143160034670.okuno.kohji@jp.panasonic.com> <20100118.160456.519459540419521301.okuno.kohji@jp.panasonic.com> Organization: Panasonic Corporation X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Bug about sched_4bsd? 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: Tue, 19 Jan 2010 04:34:59 -0000 Hello, >>> I'm not sure if this patch breaks any invariant, if you may test I >>> would appreciate: >>> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff >>> >>> Reviews and comments are appreciated. >>> BTW, nice catch. Why did you introduce "td->td_lock" to the kernel? I think that this reason is an improvment of the performance by avoiding the competition of the only lock. If it is a correct anser, a sleeping thread shoud not set &sched_lock to td->td_lock, I think. Could you comment, please? Thank you, Kohji Okuno > Hello, > > I have a question. > > The sleeping thread (on turnstile or on sleepque) can set sched_lock > to td_lock, kernel are allowed? > > Best regards, > Kohji Okuno. > >> Hello, >> >> Thank you, Attilio. >> I checked your patch. I think that your patch is better. >> I tested the patch quickly, and I think it's OK. >> # This probrem does not occur easily :-< >> >> >> What do you think about maybe_resched()? >> I have never experienced about maybe_resched(), but I think that the >> race condition may occur. >> >> <> >> sched_4bsd.c: maybe_resched() >> sched_4bsd.c: resetpriority_thread() >> sched_4bsd.c: sched_nice() get thread_lock(td) >> kern_resource.c: donice() >> kern_resource.c: setpriority() get PROC_LOCK() >> >> static void >> maybe_resched(struct thread *td) >> { >> THREAD_LOCK_ASSERT(td, MA_OWNED); >> if (td->td_priority < curthread->td_priority) >> curthread->td_flags |= TDF_NEEDRESCHED; >> } >> >> I think, when td->td_lock is not &sched_lock, curthread->td_lock is >> not locked in maybe_resched(). >> >> Best regards, >> Kohji Okuno. >> >> From: Attilio Rao >> Subject: Re: Bug about sched_4bsd? >> Date: Mon, 18 Jan 2010 03:58:41 +0100 >> Message-ID: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50@mail.gmail.com> >> >>> 2010/1/17 Kohji Okuno : >>>> Hello, >>>> >>>> Could you check sched_4bsd.patch, please? >>> >>> I think, instead, that what needs to happen is to have sched_switch() >>> to do a lock handover from sleepq/turnstile spinlock to schedlock. >>> That way, if threads are willing to contest on td_lock they will be >>> still inhibited. >>> I'm not sure if this patch breaks any invariant, if you may test I >>> would appreciate: >>> http://www.freebsd.org/~attilio/sched_4bsd_schedlock.diff >>> >>> Reviews and comments are appreciated. >>> BTW, nice catch. >>> >>> Attilio >>> >>> >>> -- >>> Peace can only be achieved by understanding - A. Einstein >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >