Re: [PATCH 01/02] cpuset memory spread slab cache filesys

[Paul Jackson <pj@sgi.com>]

> >  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
-
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/