Does anybody knows howto do something similiar on a linux 2.6?

root@solaris #psrinfo
0 on-line since 06/11/2007 18:03:33
2 on-line since 06/11/2007 18:03:18
16 on-line since 06/11/2007 18:03:33
18 on-line since 06/11/2007 18:03:33

root@solaris# prset -c 16 18

root@solaris# ps -ef |grep oracle |psrset -b 1 `awk '{print $2}'`

Keep in mind that this makes processor 16 and 18 to execute only all oracle processes (and further childs)

I'm allways listen that linux is prepared to the enterprise market, so please be my guest..

Fuck, yes! It's called CPU Affinity.

http://www.kernel.org/pub/linux/kernel/p...
http://kbase.redhat.com/faq/FAQ_80_3918....
http://www.cyberciti.biz/tips/setting-pr...
http://kevinclosson.wordpress.com/2007/0...

man 1 taskset ?

Hi Vitor,

Didn't you wonder why i underline the word "only" in text?

Process Binding on linux can be made since 2003 (linux 2.5 of course) the problem is that is non-exclusive/non-fencing, meaning i can put the oracle processes in that processors but they will not be the only ones, since the kernel will execute others random processes on it too.

This is bad if you want to do a CPU benchmark for an specified application for example

Nuno, not that simple is it ;)

Well, I'll admit upfront that I'm not really a Solaris guy, but after reading psrset manpage I don't see where it guarantees nothing else will ever be scheduled on the CPUs you request. So, the behaviour is basically the same as Linux's sched_setaffinity, AFAICT.

Am I wrong? I looked at the manpage of an oldish Solaris, though.

But it is possible to run nothing else on a given cpu, it just takes a little bit of extra effort. Given task X, and cpus Y and Z:

- reroute all irqs to cpu Y
- set all running processes to cpu Y
- set the process X to cpu Z
- change process X scheduling class to sched_fifo with a static priority of 99

I _suppose_ nothing else will be able to run on that cpu, given this scenario. 2 lines of shell? :)

Or we could, of course, use CPUSETs, which are not only a real solution instead of a 2 minute hack, but also much more flexible and friendly.

Nuno,

I know solaris will not schedule more processes (except the childs) on the CPUs i request from a practical experience view.

On Google i find:

"Both Linux and the Solaris OS support the notion of binding a process or thread to a processor. Linux allows binding to a set of processors for non-exclusive use of those processors. The Solaris OS allows binding to a set of processors for exclusive use, (that is, CPU fencing), but does not allow binding to a group for non-exclusive use (except via Solaris Zones?)"

As we spoke early on Gtalk, your workaround only works for two processors machine, because the processor binding is inherit all forks from init would never be out of processor Y in this case, and the third (n) processor would never receive any process. What a waste of money ;)

Yes, i knew about CPUSETs, but in that time it was need a kernel patch. Nowadays this is implement via filesystem and as you point out, this is already support on a vanilla kernel. Is a shame the documentation for so important feature seams to be only available on kernel source.
Even with a ugly solution (mounts,mkdir,echos,wtf?) linux pass the test , now i can put some of them in pré-production environment to see what happens.

Apparently FreeBSD has cpu fencing:
http://cn.opensolaris.org/files/solaris_...

Just a few more comments:

You make it sound like CPUSETs are a recent thing, but they're not. They have been implemented in Linux in one form or another at least since 2003, although in those days they weren't part of the kernel proper, naturally, as they were a somewhat invasive feature and pretty much under heavy development. They were eventually merged in early 2005, so they've been widely available for two and half years.

You also make it sound like a gimmick, and again, imho, it's not. The fact it's controlled by a fs is just the Linux way, really. Pretty much everything is controlled by a filesystem these days -- it's the corollary of the old UNIX adage 'everything is a file'. Just try cat'ing /proc/filesystems on any box.

And to me, at least, this solution is extremely elegant in its simplicity, as it requires no userspace tools other than a shell, of course. This also means that automated manipulation, e.g. via scripts is trivially easy. But, then again, I've always been a minimalist kind of guy, so I might be biased.

But you have a point about documentation, it's by far the biggest shortcoming in Linux. Good documentation is essential, and in that respect Sun (and other commercial vendors, of course) is leaps and bounds ahead, although the kernel code itself is now being very well documented. All new code must have full 'kerneldoc' type comments, used to generate html or pdf books describing the innards of the kernel.

But still, I wish Linux Foundation or Red Hat or Novell, or somebody else for that matter, would just hire a few technical writers (like Michael Kerrisk, for example, who does a wonderful job maintaining man-pages) to team up with the developers and document everything thoroughly in a centralized repository somewhere. Hackers are notoriously poor at writing documentation.


To finish, and regarding sched_setaffinity, you are incorrect. The particular example I gave was on a two cpu, yes, but it will work for any number of cpus --- the affinity is controled by a bitmask, but to make things easier taskset also works with a list or range of cpus.

Depends i guess, for a guy who only compiles a kernel once an year, 2 years is not that long, for a guy who subscribes kernel's ML is an eternity. As you can see, even after you said on Gtalk it was on kernel since 2005, i still feel it as new,
but hey, i also see SMP support on OpenBSD as "new" since i never tested, so no discrimination here ;)

I thought taskset was some how like the old pbind solaris command, but since is able to bind for a group of CPUs and linux implementation seems not to have this condition "It is also not possible to bind every CPU in a multiprocessor system to a user processor set. At least one CPU needs to remain unbound since otherwise the kernel itself would not have any CPU left for its own processing" such as Solaris, you right about that this workaround will probably work no matter the number of processors.
I think is because of taskset do the basics jobs that CPUsets doesn´t come more mainstream, well and because taskset is a userland tool with manpage (which i really didn´t read, like you suggest early in this thread, until now ;)