Messages in this thread | | | Date | Mon, 26 Jul 2004 12:57:50 -0700 | From | Andrew Morton <> | Subject | Re: [patch] voluntary-preempt-2.6.8-rc2-J3 |
| |
Ingo Molnar <mingo@elte.hu> wrote: > > http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-J3
The bigger this thing gets, the more worried I get. Sometime this is going to need to be split up into individual fixes, and they need to be based upon an overall approach which we haven't yet settled on.
In particular your whole approach (with voluntary_need_resched()) doesn't work on SMP.
The approach I'm using is to unconditionally drop locks on every Nth pass around the loop to allow another CPU to grab the lock, do some work, drop the lock, then be preempted. eg:
@@ -773,6 +774,12 @@ int get_user_pages(struct task_struct *t struct page *map = NULL; int lookup_write = write;
+ if ((++nr_pages & 63) == 0) { + spin_unlock(&mm->page_table_lock); + cpu_relax(); + spin_lock(&mm->page_table_lock); + } + /* * We don't follow pagetables for VM_IO regions - they
This is a bit nasty, because it assumes that the other CPU will be able to get in there and acquire the lock which is in a different cpu's cache. Long transfer latencies may defeat this.
For voluntary preempt the above will need a cond_resched added to it.
So we need to come up with a suitable approach to covering voluntary and involuntary preemption on both UP and SMP and set up the header file infrastructure to support it all. After that we need to redo all the points-of-high-latency whcih have thus far been discovered to use that infrastructure.
- 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/
| |