Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jan 2017 18:03:45 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-stable@FreeBSD.org, svn-src-stable-10@FreeBSD.org
Subject:   Re: svn commit: r312666 - stable/10/sys/kern
Message-ID:  <49838a2b-c628-da8c-4c9c-4a66c83119f8@FreeBSD.org>
In-Reply-To: <20170124002712.Q903@besplex.bde.org>
References:  <201701230834.v0N8Ypnu011042@repo.freebsd.org> <20170124002712.Q903@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 23/01/2017 15:34, Bruce Evans wrote:
> On Mon, 23 Jan 2017, Andriy Gapon wrote:
> 
>> ==============================================================================
>> --- stable/10/sys/kern/sched_4bsd.c    Mon Jan 23 08:34:41 2017    (r312665)
>> +++ stable/10/sys/kern/sched_4bsd.c    Mon Jan 23 08:34:51 2017    (r312666)
>> @@ -963,8 +963,8 @@ sched_switch(struct thread *td, struct t
>>         sched_load_rem();
>>
>>     td->td_lastcpu = td->td_oncpu;
>> -    preempted = !((td->td_flags & TDF_SLICEEND) ||
>> -        (flags & SWT_RELINQUISH));
>> +    preempted = (td->td_flags & TDF_SLICEEND) == 0 &&
>> +        (flags & SW_PREEMPT) != 0;
>>     td->td_flags &= ~(TDF_NEEDRESCHED | TDF_SLICEEND);
>>     td->td_owepreempt = 0;
>>     td->td_oncpu = NOCPU;
> 
> Please also merge to FreeBSD-9.  FreeBSD-9 has best performance for a
> makeworld benchmark.

Will do.

> What is a good benchmark for showing that the fix helps?

Honestly, I do not know.  We ran into a pathology where a thread was not getting
scheduled for a long time after being preempted while in a critical section (so
the actual preemption was a voluntary switch when exiting the critical section).
 I am not sure what kind of a synthetic benchmark or a test case would readily
demonstrate the problem.

> Involuntary context switches increased by almost a factor of 2 for the
> makeworld benchmark (over nfs) recently, but that was just caused by
> pessimizations in the NIC driver.


-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49838a2b-c628-da8c-4c9c-4a66c83119f8>