[[RFC v0 0/3] Simple wait queue support] On 05/08/2015 (Wed 15:30) Daniel Wagner wrote: > Hi, > > It's a while since the last attempt by Paul to get simple wait ready > for mainline [1]. At the last realtime workshop it was discussed how > the swait implementation could be made preempt aware. Peter posted an > untested version of it here [2]. So, from memory, here are the issues or questions that need answers before we can consider trying mainline IMO. 1) naming: do we keep the swait, do we try and morph complex wait users into using cwait, or some mix of the two, or ... ? 2) placement: as I think I said before, the standalone files works for the -rt patches because it is the lowest maintenance solution, but IMO for mainline, the simple and complex versions should be right beside each other so they can be easily contrasted and compared and so any changes to one will naturally also flow to the other. 3) barrier usage: we'd had some questions and patches in the past that futz'd around with the use of barriers, and as a mainline requirement we'd need someone to check, understand and document them all properly. 4) poll_wait: currently it and poll_table_entry are both hard coupled to wait_queue_head_t -- so any users of poll_wait are not eligible for conversion to simple wait. (I just happened to notice that recently.) A quick grep shows ~500 poll_wait users. 5) the aforementioned "don't do an unbounded number of callbacks while holding the raw lock" issue. We should solve #5 for -rt regardless; I wouldn't attempt to make a new "for mainline" set again w/o some consensus on #1 and #2, and I think it would take someone like peterz/paulmck/rostedt to do #3 properly. I don't know if #4 is an issue we need to worry about right away; probably not. And I'm sure I'll think of some other issue five seconds after I hit send... Paul. -- > > In order to test it, I used Paul's two patches which makes completion > and rcu using swait instead of wait. Some small renamings were > necessary to get it working, e.g. s/swait_head/swait_queue_head/. > > My test system didn't crash or showed any obvious defects, so I > decided to apply some benchmarks utilizing mmtests. I have picked some > random tests (kernbench aim9 vmr-stream ebizz), which didn't require a > lot of tinker around to get them running. The results are here: > > baseline: v4.2-rc5-22-ged8bbba > > http://monom.org/mmtests-swait-peterz-v1/ > > I don't think the numbers are trustworthy yet. Mabye one could read > it as it doesn't explode and the numbers aren't to far away from > baseline. I need to figure out which tests are fitting for these > patches and what are the 'right' parameters for them. > > Sebastian had some comments on Peter's patch. I haven't addressed them > yet [3]. > > cheers, > daniel > > [1] https://lwn.net/Articles/616857/ > [2] http://www.spinics.net/lists/linux-rt-users/msg12703.html > [3] https://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg832142.html > > Paul Gortmaker (2): > sched/completion: convert completions to use simple wait queues > rcu: use simple wait queues where possible in rcutree > > Peter Zijlstra (1): > KVM: use simple waitqueue for vcpu->wq > > include/linux/completion.h | 8 +-- > include/linux/swait.h | 172 +++++++++++++++++++++++++++++++++++++++++++++ > kernel/rcu/tree.c | 13 ++-- > kernel/rcu/tree.h | 6 +- > kernel/rcu/tree_plugin.h | 18 ++--- > kernel/sched/Makefile | 2 +- > kernel/sched/completion.c | 32 ++++----- > kernel/sched/swait.c | 122 ++++++++++++++++++++++++++++++++ > 8 files changed, 334 insertions(+), 39 deletions(-) > create mode 100644 include/linux/swait.h > create mode 100644 kernel/sched/swait.c > > -- > 2.4.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
