> > 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 <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
