Re: Bug about sched_4bsd?

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_at_freebsd.org>
>> Subject: Re: Bug about sched_4bsd?
>> Date: Mon, 18 Jan 2010 03:58:41 +0100
>> Message-ID: <3bbf2fe11001171858o4568fe38l9b2db54ec9856b50_at_mail.gmail.com>
>> 
>>> 2010/1/17 Kohji Okuno <okuno.kohji_at_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_at_freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>> 
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>