lkml.org 
[lkml]   [2008]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH 0/4] CPUSET driven CPU isolation
David wrote:
> Move the watchdog/0 thread to a cpuset that doesn't have access to cpu 0.

I still don't understand ... you must have some context in mind that
I've spaced out ... I can't even tell if that is a statement or a
question.

> I'd hesitate to do that unless you can guarantee that restricting
> kthreads mems_allowed via the cpuset interface won't cause any problems
> either. Is there a benefit to reducing the size of a kthread's
> mems_allowed that doesn't have an adverse effect on the kernel? What
> about kswapd?

Well ... I'm suspecting we've got this portion of our discussion wrapped
around the axle one time too many.

Backing up, hopefully unwrapping, you seemed to allow moving bound tasks
only to cpusets with the same cpus (how come you didn't check for the
same memory nodes too?). If you really needed to move bound tasks at all,
then that seemed like an unnecessarily tight constraint. It wouldn't hurt
the bound task to move to another cpuset that still allowed the CPUs it was
bound to.

... but after an another iteration of that subthread ... I'm wondering
why you have to move bound tasks at all. How about PF_THREAD_BIND just
meaning (1) "can't be moved to any other cpuset", and (2) "always
placed in the top cpuset," so we don't have to worry about being unable
to move threads out of child cpusets.

Do you have any situation in which pinned threads have to be moved?

I don't. Can we just prohibit it?

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214


\
 
 \ /
  Last update: 2008-02-29 01:19    [W:0.101 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site