12 messages in org.freebsd.freebsd-archWhat is the PREEMPTION option good for?| From | Sent On | Attachments |
|---|---|---|
| Bruce Evans | Nov 18, 2006 6:17 pm | |
| Ivan Voras | Nov 18, 2006 9:55 pm | |
| Ivan Voras | Nov 23, 2006 3:57 pm | |
| Bruce Evans | Nov 24, 2006 12:09 am | |
| Robert Watson | Nov 26, 2006 9:44 am | |
| Ivan Voras | Nov 26, 2006 10:09 am | |
| Robert Watson | Nov 28, 2006 6:23 am | |
| Ivan Voras | Dec 1, 2006 4:04 am | |
| Bruce Evans | Dec 1, 2006 4:07 pm | |
| Matthew Dillon | Dec 1, 2006 8:54 pm | |
| Frank Mayhar | Dec 1, 2006 9:46 pm | |
| Bruce Evans | Dec 2, 2006 2:25 am |
| Subject: | What is the PREEMPTION option good for? | |
|---|---|---|
| From: | Ivan Voras (ivo...@fer.hr) | |
| Date: | Dec 1, 2006 4:04:15 am | |
| List: | org.freebsd.freebsd-arch | |
Robert Watson wrote:
They're independent twiddles, and can be frobbed separately. If you can easily measure performance in the different configurations, seeing a table of permutations and results would be very nice to see what happens :-).
Ok, this is what I found:
- ipiwakeup doesn't produce differences as calculated by ministat - turning off preemption produces visible differences, which are calculated by ministat to be upto 10%.
x nopreempt+ipiwakeup + preempt+ipiwakeup +--------------------------------------------------------------------------+ |+ + + + x x xx xx x| | |___________A__M________| |______MA_______| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 7 99.92 104.19 101.48 101.78429 1.4606717 + 4 90.5 95.78 94.12 93.53 2.2081365 Difference at 95.0% confidence -8.25429 +/- 2.4751 -8.10959% +/- 2.43172% (Student's t, pooled s = 1.74576)
Sorry about the small number of samples - these are collected from the system in the same state and product version (the machine was otherwise idle, etc.), but the difference is always present - I've run simpler benchmarks every few days since the discussion started and it's there.
This is on a low-end dual core Xeon (i.e. one socket, two cores, no HT), enough RAM not to swap, requests/second with high concurrency on a web application that does a lot of IPC to database & cache engines through both TCP/localhost and unix sockets.