public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: clameter@engr.sgi.com, dgc@sgi.com, steiner@sgi.com,
	Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
	clameter@sgi.com
Subject: Re: [PATCH 01/02] cpuset memory spread slab cache filesys
Date: Wed, 1 Mar 2006 10:27:57 -0800	[thread overview]
Message-ID: <20060301102757.f2eec70e.pj@sgi.com> (raw)
In-Reply-To: <200602281813.47234.ak@suse.de>

> >  1) Are you content to have such a interleave of these particular file
> >     i/o slabs triggered by a mm/mempolicy.c option?  Or do you think
> >     we need some sort of task external API to invoke this policy?
> 
> Task external. mempolicy.c has no good way to handle multiple policies
> like this. I was thinking of a simple sysctl

No need to implement a sysctl for this.  The current cpuset facility
should provide just what you want, if I am understanding correctly.

It would be really easy.  Run with a kernel that has cpusets configured
in.  One time at boot, enable memory spreading for these slabs:
    test -d /dev/cpuset || mkdir /dev/cpuset
    mount -t cpuset cpuset /dev/cpuset
    echo 1 > /dev/cpuset/memory_spread_slab	# enable system wide

That's all you need to do to enable this system wide.

With this, tasks will be spreading these selected slab caches,
independently of whatever mempolicy they have.

To disable this memory spreading system wide:
    echo 0 > /dev/cpuset/memory_spread_slab	# disable system wide

If you want to control which tasks have these slab spread, then
it is just a few more lines once at boottime.  The following
lines make a second cpuset 'spread_tasks'.  Tasks in this second
cpuset will be spread; the other tasks in the root cpuset won't be
spread.

One time at boot:
    test -d /dev/cpuset || mkdir /dev/cpuset
    mount -t cpuset cpuset /dev/cpuset
    mkdir /dev/cpuset/spread_tasks
    cat /dev/cpuset/cpus > /dev/cpuset/spread_tasks/cpus
    cat /dev/cpuset/mems > /dev/cpuset/spread_tasks/mems
    echo 1 > /dev/cpuset/spread_tasks/memory_spread_slab

Then during operation, for each task $pid that is to be spread:
    echo $pid > /dev/cpuset/spread_tasks/tasks	# enable for $pid

or to disable that spreading for a pid:
    echo $pid > /dev/cpuset/tasks		# disable for $pid

These echo's can be done with open/write/close system calls if you
prefer.

The first two echos above would correspond to a sysctl that applied
system wide, enabling or disabling memory spreading on these slabs for
all tasks.  The last two echo's correspond directly to a sysctl that
applies to a single specified pid.

Why do a new sysctl, when the existing open/write/close system calls
can do the same thing?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

  reply	other threads:[~2006-03-01 18:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-27  7:02 [PATCH 01/02] cpuset memory spread slab cache filesys Paul Jackson
2006-02-27  7:02 ` [PATCH 02/02] cpuset memory spread slab cache format Paul Jackson
2006-02-27 19:34 ` [PATCH 01/02] cpuset memory spread slab cache filesys Andi Kleen
2006-02-27 20:16   ` Paul Jackson
2006-02-27 20:36     ` Christoph Lameter
2006-02-27 20:49       ` Andi Kleen
2006-02-27 20:56         ` Christoph Lameter
2006-02-27 21:02           ` Andi Kleen
2006-02-27 22:14             ` Christoph Lameter
2006-02-27 22:39               ` Andi Kleen
2006-02-27 23:13                 ` Christoph Lameter
2006-02-28  1:56                   ` Paul Jackson
2006-02-28 17:13                     ` Andi Kleen
2006-03-01 18:27                       ` Paul Jackson [this message]
2006-03-01 18:34                         ` Andi Kleen
2006-03-01 18:38                           ` Christoph Lameter
2006-03-01 18:58                           ` Paul Jackson
2006-03-01 19:21                             ` Andi Kleen
2006-03-01 20:53                               ` Paul Jackson
2006-03-01 20:59                                 ` Andi Kleen
2006-03-01 21:19                                   ` Paul Jackson
2006-03-01 21:21                                     ` Andi Kleen
2006-03-01 22:20                                       ` Christoph Lameter
2006-03-01 22:52                                         ` Paul Jackson
2006-03-02  1:57                                         ` Andi Kleen
2006-03-02 14:38                                           ` Christoph Lameter

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=20060301102757.f2eec70e.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=ak@suse.de \
    --cc=clameter@engr.sgi.com \
    --cc=clameter@sgi.com \
    --cc=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steiner@sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox