From: Rolf Fokkens <fokkensr@linux06.vertis.nl>
To: Robert Love <rml@tech9.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: cpus_allowed
Date: Sat, 13 Oct 2001 17:37:33 -0700 [thread overview]
Message-ID: <01101317373300.02554@home01> (raw)
In-Reply-To: <01101316594000.02369@home01> <1002990137.868.59.camel@phantasy>
In-Reply-To: <1002990137.868.59.camel@phantasy>
On Saturday 13 October 2001 09:22, Robert Love wrote:
> On Sat, 2001-10-13 at 19:59, Rolf Fokkens wrote:
> > I'm sure I'm overlooking something, but that doesn't help me finding the
> > answer. So would someone be so kind to enlighten me?
>
> It is initialized to -1 (0xffffffff) by struct definition at
> linux/kernel/sched.h. Since it is a mask, this means all CPUs
> (obviously).
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.
next prev parent reply other threads:[~2001-10-13 16:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-13 23:59 cpus_allowed Rolf Fokkens
2001-10-13 16:22 ` cpus_allowed Robert Love
2001-10-13 16:14 ` cpus_allowed Tim Hockin
2001-10-14 0:37 ` Rolf Fokkens [this message]
2001-10-13 16:23 ` cpus_allowed Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01101317373300.02554@home01 \
--to=fokkensr@linux06.vertis.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.