Re: [RFC v0 0/3] Simple wait queue support
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2015-08-06 19:31:26
Also in:
lkml
On Thu, 6 Aug 2015 15:22:45 -0400 Paul Gortmaker [off-list ref] wrote:
[[RFC v0 0/3] Simple wait queue support] On 05/08/2015 (Wed 15:30) Daniel Wagner wrote:quoted
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 ... ?
I would say keep swait for now. Convert a few major hitters to it to test it out. After a release or two, create a cwait, and start converting the complex waits to them. Then after a period of stability, convert the normal wait_queues to be implemented with swait, and remove the swait from the kernel.
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.
I'm agnostic on this part.
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.
Sounds like a plan.
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.
Looks like a good candidate to test the cwait on :-)
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...
5... 4... 3... 2... 1... (where's the other issue?) -- Steve