Re: parallels pci id
patch was corrected after comments from Brad (in CC) please commit On 18:26 Tue 11 Oct , Sergey Bronnikov wrote: Usually pci vendor and products id generated in source tree from sys/dev/pcidevs. But that file has wrong vendor and product id's for Parallels virtual devices. I am change it to proper values: vga1 at pci1 dev 0 function 0 Parallels Video rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) Parallels Tools rev 0x00 at pci0 dev 3 function 0 not configured Please review and commit patch. P.S. cvs annotate shows me source of that incorrect data: 1.1082 (brad 25-Jun-06): vendor PARALLELS 0x Parallels 1.1082 (brad 25-Jun-06): /* Parallels products */ 1.1082 (brad 25-Jun-06): product PARALLELS TOOLS 0x1112 Tools 1.1082 (brad 25-Jun-06): product PARALLELS VIDEO 0x1121 Video -- sergeyb@ -- sergeyb@ Index: pcidevs === RCS file: /home/estet/source/openbsd/src/sys/dev/pci/pcidevs,v retrieving revision 1.1623 diff -u -p -r1.1623 pcidevs --- pcidevs 23 Sep 2011 08:54:25 - 1.1623 +++ pcidevs 11 Oct 2011 21:20:56 - @@ -311,6 +311,7 @@ vendor JMICRON 0x197b JMicron vendor PHISON 0x1987 Phison vendor ASPEED 0x1a03 ASPEED Technology vendor AWT 0x1a3b AWT +vendor PARALLELS2 0x1ab8 Parallels vendor FUSIONIO0x1aed Fusion-io vendor QUMRANET0x1af4 Qumranet vendor ASMEDIA 0x1b21 ASMedia @@ -4683,6 +4684,8 @@ product PE GNIC2 0x0911 PMC/GNIC2 /* Parallels products */ product PARALLELS TOOLS0x1112 Tools product PARALLELS VIDEO0x1121 Video +product PARALLELS2 TOOLS 0x4000 Tools +product PARALLELS2 VIDEO 0x4005 Video /* PC Tech products */ product PCTECH RZ1000 0x1000 RZ1000
Scheduler improvements
Hi people, attached is a patch that basically rewrites the CPU scheduler. It replaces the multilevel feedback queue currently employed with an earliest effective deadline first approach, similar to the BrainFuck Scheduler for Linux. My main motivation for rewriting the scheduler was mplayer getting killed all the time because it went over its share of CPU resources, something which can not happen with the patch I wrote. The algorithms employed simply assigns a (soft) deadline to each process, which is calculated based solely on nice value and selects the next process to execute based on the earliest deadline in the runqueue. If more than one deadline is missed, the first one encountered in FIFO order (FIFO with respect to insertion into the runqueue) with a deadline smaller than current time is selected. This prevents processes from yielding a small time before their timeslice expires to fool the scheduler into leaving them in their respective priority queue, thus preventing multiple processes from teaming up to starve others of CPU runtime. I did a few benchmarks to test the difference between the original and my patched scheduler to see whether there was any improvements. The tool I used was sysbench (with both CPU and Threads benchmarks). There are a few graphs of the tests at http://gurkenfunk.de/projects/openbsd-eevdf, but it looks as if my patches improve latency on workloads with high CPU usage, little I/O and a relatively large amount of threads. I'm not aiming for a yeah, nice, we'll merge it on this, but rather for suggestions whether it's worth anyones time to pursue this further. Oh, also, with the patch, the scheduler code is 225 lines shorter and IMHO a bit easier to understand. -- Gregor Best ? sys/.git ? sys/.gitignore ? sys/vim.core ? sys/arch/alpha/stand/installboot/installboot.8.manlint ? sys/arch/alpha/stand/setnetbootinfo/setnetbootinfo.8.manlint ? sys/arch/amd64/amd64/.acpi_machdep.c.swp ? sys/arch/amd64/include/.cpu.h.swp ? sys/arch/armish/stand/boot/boot.8.manlint ? sys/arch/aviion/stand/a2coff/a2coff.8.manlint ? sys/arch/hppa/stand/boot/boot.8.manlint ? sys/arch/hppa/stand/mkboot/mkboot.8.manlint ? sys/arch/hppa64/stand/boot/boot.8.manlint ? sys/arch/hppa64/stand/mkboot/mkboot.8.manlint ? sys/arch/i386/stand/biosboot/biosboot.8.manlint ? sys/arch/i386/stand/boot/boot.8.manlint ? sys/arch/i386/stand/cdboot/cdboot.8.manlint ? sys/arch/i386/stand/installboot/installboot.8.manlint ? sys/arch/i386/stand/pxeboot/pxeboot.8.manlint ? sys/arch/landisk/stand/boot/boot.8.manlint ? sys/arch/landisk/stand/mbr/mbr.8.manlint ? sys/arch/landisk/stand/xxboot/xxboot.8.manlint ? sys/arch/mvme68k/stand/installboot/installboot.8.manlint ? sys/arch/mvme88k/stand/installboot/installboot.8.manlint ? sys/arch/sgi/stand/sgivol/sgivol.8.manlint ? sys/arch/socppc/stand/boot/boot.8.manlint ? sys/arch/socppc/stand/mkboot/mkboot.8.manlint ? sys/arch/sparc/stand/installboot/installboot.8.manlint ? sys/arch/sparc64/stand/installboot/installboot.8.manlint ? sys/arch/zaurus/stand/zboot/boot.8.manlint ? sys/dev/microcode/atmel/atu-at76c503-i3863-ext ? sys/dev/microcode/atmel/atu-at76c503-i3863-int ? sys/dev/microcode/atmel/atu-at76c503-rfmd-acc-ext ? sys/dev/microcode/atmel/atu-at76c503-rfmd-acc-int ? sys/dev/microcode/atmel/atu-at76c505-rfmd-ext ? sys/dev/microcode/atmel/atu-at76c505-rfmd-int ? sys/dev/microcode/atmel/atu-intersil-ext ? sys/dev/microcode/atmel/atu-intersil-int ? sys/dev/microcode/atmel/atu-rfmd-ext ? sys/dev/microcode/atmel/atu-rfmd-int ? sys/dev/microcode/atmel/atu-rfmd2958-ext ? sys/dev/microcode/atmel/atu-rfmd2958-int ? sys/dev/microcode/atmel/atu-rfmd2958smc-ext ? sys/dev/microcode/atmel/atu-rfmd2958smc-int ? sys/dev/microcode/atmel/build ? sys/dev/microcode/bnx/bnx-b06 ? sys/dev/microcode/bnx/bnx-b09 ? sys/dev/microcode/bnx/bnx-rv2p ? sys/dev/microcode/bnx/bnx-xi-rv2p ? sys/dev/microcode/bnx/bnx-xi90-rv2p ? sys/dev/microcode/bnx/build ? sys/dev/microcode/cirruslogic/build ? sys/dev/microcode/cirruslogic/cs4280 ? sys/dev/microcode/fxp/build ? sys/dev/microcode/fxp/fxp-d101a ? sys/dev/microcode/fxp/fxp-d101b0 ? sys/dev/microcode/fxp/fxp-d101ma ? sys/dev/microcode/fxp/fxp-d101s ? sys/dev/microcode/fxp/fxp-d102 ? sys/dev/microcode/fxp/fxp-d102c ? sys/dev/microcode/fxp/fxp-d102e ? sys/dev/microcode/kue/build ? sys/dev/microcode/kue/kue ? sys/dev/microcode/myx/build ? sys/dev/microcode/myx/myx-eth_z8e ? sys/dev/microcode/myx/myx-ethp_z8e ? sys/dev/microcode/ral/build ? sys/dev/microcode/ral/ral-rt2561 ? sys/dev/microcode/ral/ral-rt2561s ? sys/dev/microcode/ral/ral-rt2661 ? sys/dev/microcode/ral/ral-rt2860 ? sys/dev/microcode/rum/build ? sys/dev/microcode/rum/rum-rt2573 ? sys/dev/microcode/rum/run-rt2870 ? sys/dev/microcode/rum/run-rt3071 ? sys/dev/microcode/tht/build ? sys/dev/microcode/tht/tht ? sys/dev/microcode/tigon/build ? sys/dev/microcode/tigon/tigon1 ? sys/dev/microcode/tigon/tigon2 ? sys/dev/microcode/tusb3410/build ? sys/dev/microcode/tusb3410/tusb3410 ?
Re: Scheduler improvements
Hi people, [...] I'm not aiming for a yeah, nice, we'll merge it on this, but rather for suggestions whether it's worth anyones time to pursue this further. This is interesting, there might be a good outcome of this diff eventually. However as of now: - you have removed the bunch of code which tries to make sure processes do not hop between cpus unless there is a gain in doing so, on MP kernels. Did you try your diff on a MP kernel? - non-tabbed indent is evil. And makes the diff harder to read. - I see many locks removed in there, and moving information to the proc structure does not explain all of them. This gives a bad gut feeling about the behaviour of this on MP kernels. A really bad gut feeling. - you have changed the roundrobin duration from (hz / 10 to (hz / 100). However, this computation yields zero on platforms where hz 100, which is not a good idea. The only assumptions you can make about hz is that 50 = hz = 1024. - you removed the enforcement of RLIMIT_CPU. No way. Over my dead body. - I also don't really like switching from NQS run queues to a single one. I understand you need this to be able to compare the deadlines with only one queue walk, but this can become expensive with many processes in the runqueue... - your priority computation are unexplained magic. What does 20 mean? Shouldn't at least one of them be derived from `hz'? Why 1 versus 5? Are you sure the values you are computed are always within the bounds you are expecting? Why isn't there any comment about these computations? Miod
Re: Scheduler improvements
On Wed, Oct 12, 2011 at 05:51:33PM +, Miod Vallat wrote: Hi people, [...] I'm not aiming for a yeah, nice, we'll merge it on this, but rather for suggestions whether it's worth anyones time to pursue this further. This is interesting, there might be a good outcome of this diff eventually. However as of now: - you have removed the bunch of code which tries to make sure processes do not hop between cpus unless there is a gain in doing so, on MP kernels. Did you try your diff on a MP kernel? [...] Yes. Almost all builds I have done so far were MP kernels, which I run almost all the time (I switch to un-patched kernels for benchmarks only). I'll do a benchmark with an SP build though to check whether there are any negative impacts. - non-tabbed indent is evil. And makes the diff harder to read. [...] I will clean that up. - I see many locks removed in there, and moving information to the proc structure does not explain all of them. This gives a bad gut feeling about the behaviour of this on MP kernels. A really bad gut feeling. [...] Works fine with two cores, but I can see where that feeling comes from. I'll add some more explanations to my changes. - you have changed the roundrobin duration from (hz / 10 to (hz / 100). However, this computation yields zero on platforms where hz 100, which is not a good idea. The only assumptions you can make about hz is that 50 = hz = 1024. [...] Good point. I'll change that. - you removed the enforcement of RLIMIT_CPU. No way. Over my dead body. - I also don't really like switching from NQS run queues to a single one. I understand you need this to be able to compare the deadlines with only one queue walk, but this can become expensive with many processes in the runqueue... [...] Right. I'm planning to move this to a real priority queue via some sort of heap, so lookups and insertions can be done in O(log n) instead of O(n). - your priority computation are unexplained magic. What does 20 mean? Shouldn't at least one of them be derived from `hz'? Why 1 versus 5? Are you sure the values you are computed are always within the bounds you are expecting? Why isn't there any comment about these computations? [...] Deriving them from hz didn't cross my mind but you are right of course. I chose the 5 because that makes for a relatively linear increase in the deadlines while not overflowing the value of .tv_usec. I'll add some explanations though. Miod Thanks a lot for your time and suggestions. -- Gregor Best [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Scheduler improvements
I like what I see. It could be the start for the means of managing a single socket's queue of processes. You do mention that this won't really scale beyond roughly 8 cores. I would love to see you extend this with a 2D array of weights that can be populated by various means (run-time testing, or ACPI tables, etc) with the relative costs of moving a process from one core to another (or one scheduling queue to another, if queue's are assigned to a set of cores, say a socket full of cores). In this way, we may be able to have cores shut down by modifying these weights based on demand/load. While I agree with your comments that OpenBSD was not originally made for lots of cpu/cores, I don't really wish to entertain huge steps backwards on that front. The rthreads work (amoung other work) has been done with an eye towards more efficiently using MP systems. Again, I like this, looks simpler. Let's see you try and solve more of the MP parts as well. :) -Toby.
You're Invited!
You're Invited to join my friends network, check my profile here: http://dallanij.zoomshare.com/files/sexygirl.htm
