Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Feb 2008 20:40:37 -0500 (EST)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        Brooks Davis <brooks@freebsd.org>, Andrew Gallatin <gallatin@cs.duke.edu>, Alfred Perlstein <alfred@freebsd.org>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, David Xu <davidxu@freebsd.org>
Subject:   Re: cpuset and affinity implementation
Message-ID:  <Pine.GSO.4.64.0802252003060.3971@sea.ntplx.net>
In-Reply-To: <20080225143222.B920@desktop>
References:  <20080220175532.Q920@desktop> <20080220213253.A920@desktop> <20080221092011.J52922@fledge.watson.org> <20080222121253.N920@desktop> <20080222231245.GA28788@lor.one-eyed-alien.net> <20080222134923.M920@desktop> <20080223194047.GB38485@lor.one-eyed-alien.net> <20080223111659.K920@desktop> <20080223213507.GD39699@lor.one-eyed-alien.net> <20080224001902.J920@desktop> <20080225231747.GT99258@elvis.mu.org> <20080225143222.B920@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Feb 2008, Jeff Roberson wrote:

> On Mon, 25 Feb 2008, Alfred Perlstein wrote:
>
>> Jeff, this is very cool.  I do have one issue though:
>> 
>> + * A thread may not be assigned to a a group seperate from other threads 
>> in
>> + * the process.  This is to remove ambiguity when the setid is queried 
>> with
>> + * a pid argument.  There is no other technical limitation.
>> 
>> Am I understanding things correctly such that within a process there
>> can only be one "set"?
>> 
>> If so this restricts some of the benifits you get with sets and
>> binding.
>> 
>> An example would be some sort of system with multiple CPUs where some
>> are assigned specifically for pseudo-realtime processing and others are for
>> general control things such as cli, stats, etc.
>> 
>> In our case we would like to be able to run some threads on specific
>> cpu sets, and other threads to be run anywhere on the control CPUs.
>> 
>> Can this be done with this API?
>
> Individual threads can be bound to any cpu or group of cpus within the set. 
> So if you just make a set that includes all cpus in the system you can then 
> bind your realtime threads to specific cpus and the other threads to the 
> remainder.  You will have to specifically bind each thread however.
>
> The reason individual threads can't be assigned to groups is because 
> cpuset_getid() for a pid wouldn't make sense then and I expect administrators 
> to be mostly interested in managing groups of processes.

If the administrator sets up a set of CPUs specifically for
real-time and another set for non-real-time, you may want to
bind some threads to the real-time set, and leave other threads
unbound (or even bound to the non-real-time set).  In this
case, I think cpuset_getid() should either return the default
cpuset of all cpus in the system, or the last cpuset to
which the process was bound.

But regardless, I think binding a thread to a different
processor set should be allowed and should override its
inherent binding of the process' processor set.
Hmm, I guess in this case, a subsequent binding of the
process to a processor set should probably override any
per-thread bindings.

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0802252003060.3971>