Messages in this thread | | | Date | Tue, 10 Jun 2008 11:00:01 -0700 | From | Max Krasnyansky <> | Subject | Re: [patch] sched: prevent bound kthreads from changing cpus_allowed |
| |
Oleg Nesterov wrote: > On 06/10, Max Krasnyansky wrote: >> Peter Zijlstra wrote: >>> Per cpu workqueues should stay on their cpu. >>> >>> What you're really looking for is a more fine grained alternative to >>> flush_workqueue(). >> Actually I had a discussion on that with Oleg Nesterov. If you remember my >> original solution (ie centralized cpu_isolate_map) was to completely redirect >> work onto other cpus. Then you pointed out that it's the flush_() that really >> makes the box stuck. So I started thinking about redoing the flush. While >> looking at the code I realized that if I only change the flush_() then queued >> work can get stale so to speak. ie Machine does not get stuck but some work >> submitted on the isolated cpus will sit there for a long time. Oleg pointed >> out exact same thing. So the simplest solution that does not require any >> surgery to the workqueue is to just move the threads to other cpus. > > Cough... I'd like to mention that I _personally agree with Peter, cwq->thread's > should stay on their cpu. I never argued against the _should stay_ ;-). What I'm arguing against is the _must stay_ which is a big difference. I'll start a separate thread on this.
> I just meant that from the workqueue.c pov it is (afaics) OK to move cwq->thread > to other CPUs, in a sense that this shouldn't add races or hotplug problems, etc. Yep. That's what I was referring to in the explanation that I send to Peter.
> But still this doesn't look right to me. Yeah, it's all about perceptions. We'll fix that ;-).
Max
| |