283210 - [BeOS] Locking primitives don't need reschedule

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[tqh]

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b2) Gecko/20050221 Firefox/1.0+
Build Identifier: 

In bthreads all locking primitives calls to release_sem also reschedules the
thread, which may be unwanted in Mozilla.

Reproducible: Always

Steps to Reproduce:

Comment 1

[tqh]

Attachment: Use the B_DO_NOT_RESCHEDULE flag.

From the Bebook:
Normally, releasing a semaphore automatically invokes the kernel's scheduler.
In other words, when your thread calls release_sem(), you're pretty much 
guaranteed that some other thread will be switched in immediately afterwards,
even if your thread hasn't gotten its fair share of CPU time. If you want to 
subvert this automatism, call release_sem_etc() with a flags value of
B_DO_NOT_RESCHEDULE. Preventing the automatic rescheduling is particularly
useful if you're releasing a number of different semaphores all in a row: By
avoiding the rescheduling you can prevent some unnecessary context switching.

Comment 2

[Sergei Dolgov]

Comment on attachment 175195 [details] [diff] [review]
Use the B_DO_NOT_RESCHEDULE flag.

r=sergei_d
Looks reasonable to avoid switching overhead

Comment 3

[Wan-Teh Chang]

Comment on attachment 175195 [details] [diff] [review]
Use the B_DO_NOT_RESCHEDULE flag.

I agree this seems like a good change to
improve performance.

Comment 4

[tqh]

I need someone to check this in.

Comment 5

[Wan-Teh Chang]

Patch checked in on the NSPR trunk (NSPR 4.6) and
NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.8 Beta 2).

Comment 6

[Sergei Dolgov]

Tqh, after more intensive testing i got feeling that with the patch BeZilla gone
less "multitasking".
E.g. if you have some page loading in background, it goes harder to open next
tab with Alt+T or scroll current page or type text in URL bar.

But i don't know how to do objective testing:(

Comment 7

[tqh]

Yes, it is less 'multitasking' because that's what this patch does. It allows a
thread to continue running more of the time-slice it's supposed to run instead
of giving much of it away because it released a semaphore. This means less
switching between threads, but also less wasted time on switching. It should
reduce cpu-load on processing intensive tasks (loading, downloading, parsing),
but quick tasks (like UI usually is) will get a minor setback. 

Startup is faster, cvar and cvar2 (use a cmdline flag to see timing) in nspr
tests are faster. (Do 'make cvar cvar2' in there and make a symbolic link lib to
dist/lib to run).

The snappiness will probably be better when we set our rendering proxy thread
(for all the BWindow threads) to be of B_DISPLAY_PRIORITY as it should. It's one
of the patches I will work on once our native app patches gets commited. You can
try doing that today in nsAppshell Spinup or Run.