Date: Tue, 19 Jan 2010 13:34:55 +0900 (JST) From: Kohji Okuno <okuno.kohji@jp.panasonic.com> To: attilio@freebsd.org, jroberson@jroberson.net Cc: freebsd-current@freebsd.org Subject: Re: Bug about sched_4bsd? Message-ID: <20100119.133455.123339447290605132.okuno.kohji@jp.panasonic.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> >> <<Back Trace>> >> 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 <attilio@freebsd.org> >> 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 <okuno.kohji@jp.panasonic.com>: >>>> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100119.133455.123339447290605132.okuno.kohji>