![]() | |||||||||||
Messages in this thread |
Herbert, Thanks a lot for the details, I will give it a try once again. Looks like fairness in this scenario simply requires sched_hard settings. Herbert... I don't know why you've decided that my goal is to prove that your scheduler is bad or not precise. My goal is simply to investigate different approaches and make some measurements. I suppose you can benefit from such a volunteer, don't you think so? Anyway, thanks again and don't be cycled on the idea that OpenVZ are so cruel bad guys :) Thanks, Kirill > well, your mistake seems to be that you probably haven't > tested this yet, because with the following (simple) > setups I seem to get what you consider impossible > (of course, not as precise as your scheduler does it) > > > vcontext --create --xid 100 ./cpuhog -n 1 100 & > vcontext --create --xid 200 ./cpuhog -n 1 200 & > vcontext --create --xid 300 ./cpuhog -n 1 300 & > > vsched --xid 100 --fill-rate 1 --interval 6 > vsched --xid 200 --fill-rate 2 --interval 6 > vsched --xid 300 --fill-rate 3 --interval 6 > > vattribute --xid 100 --flag sched_hard > vattribute --xid 200 --flag sched_hard > vattribute --xid 300 --flag sched_hard > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 39 root 25 0 1304 248 200 R 74 0.1 0:46.16 ./cpuhog -n 1 300 > 38 root 25 0 1308 252 200 H 53 0.1 0:34.06 ./cpuhog -n 1 200 > 37 root 25 0 1308 252 200 H 28 0.1 0:19.53 ./cpuhog -n 1 100 > 46 root 0 0 1804 912 736 R 1 0.4 0:02.14 top -cid 20 > > and here the other way round: > > vsched --xid 100 --fill-rate 3 --interval 6 > vsched --xid 200 --fill-rate 2 --interval 6 > vsched --xid 300 --fill-rate 1 --interval 6 > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 36 root 25 0 1304 248 200 R 75 0.1 0:58.41 ./cpuhog -n 1 100 > 37 root 25 0 1308 252 200 H 54 0.1 0:42.77 ./cpuhog -n 1 200 > 38 root 25 0 1308 252 200 R 29 0.1 0:25.30 ./cpuhog -n 1 300 > 45 root 0 0 1804 912 736 R 1 0.4 0:02.26 top -cid 20 > > > note that this was done on a virtual dual cpu > machine (QEMU 8.0) with 2.6.16-vs2.1.1-rc16 and > that there were roughly 25% idle time, which I'm > unable to explain atm ... > > feel free to jump on that fact, but I consider > it unimportant for now ... > > best, > Herbert > > >>Thanks, >>Kirill > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-04-13 08:50 [from the cache] ©2003-2008 | |||||||||||