All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.