Messages in this thread | | | Date | Wed, 1 Mar 2006 10:27:57 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH 01/02] cpuset memory spread slab cache filesys |
| |
> > 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/
| |