Re: Some interesting results from tweaking spinlocks
От | Brent Verner |
---|---|
Тема | Re: Some interesting results from tweaking spinlocks |
Дата | |
Msg-id | 20020106014845.GA8280@rcfile.org обсуждение исходный текст |
Ответ на | Re: Some interesting results from tweaking spinlocks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Some interesting results from tweaking spinlocks
Re: Some interesting results from tweaking spinlocks |
Список | pgsql-hackers |
[2002-01-05 17:04] Tom Lane said: | Brent Verner <brent@rcfile.org> writes: | > Using a single-processor machine, we're not going to get any lower | > sleep times than ~10ms from either usleep or select on linux, and | > usleep is always longer. | | Ah, so usleep is just being stricter about rounding up the requested | delay? That would explain the results all right. The only difference I see is that sys_nanosleep gets its actual timeout value using timespec_to_jiffies(), and do_select leaves the specified delay untouched. | > Looks like increasing spins allows | > the process to get the lock before the usleep/select is run | | Right. Up to a point, increasing spins improves the odds of acquiring | the lock without having to release the processor. | | What I should've thought of is to try sched_yield() as well, which is | the operation we *really* want here, and it is available on this version | of Linux. Off to run another batch of tests ... yes. using just sched_yield() inside the TAS loop appears to give better performance on both freebsd and linux (single-proc); in particular, it _looks_ like there is a 8-10% performance gain at 32 clients. btw, what are y'all using to generate these nifty graphs? thanks. brent -- "Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing." -- Duane Allman
В списке pgsql-hackers по дате отправления: