Silly me, I didn't check the header files.
> Most of the CPU affinity patches you see were written before
> cpus_allowed. They go through all sorts of trouble to do what the OS
> now does on its own. If you want to change CPU affinity then you just
> need a patch that adds a syscall or proc interface for setting the
> cpus_allowed mask.
Just read the "Linux Scalability Effort" (LSE) on Sourceforge. The concept of
limitiming applications to certain resources is appealing to me. With the use
of cpus_allowed it's not to hard to restrict CPU power for some applications.
I'm thinking of the following: we're running about 12 (!) Oracle databases on
1 Linux Server with 4 CPU's. One of the databases is a datawarehouse database
which handles all kinds of heavy queries. Assuming that the machine has
enough memory (which is the case) restricting this database to certain CPU's
could be very useful.
I have no idea however what the right API would be. LSE suggests a ulimit
like setting. In this Oracle example one listener handles connections to all
databases on the machine, it does so by forking and executing the database
binary with some specific environment settings per database. So ulimit won't
handle it. The solution might be to run 2 listeners, one with
restricted cpus_allowed and the other one with unrestricted cpus_allowed.
-
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/