From: shaheed <srhaque@iee.org>
To: mingo@elte.hu
Cc: linux-kernel@vger.kernel.org, rml@tech9.net
Subject: [RFC] patch to allow CPUs to be reserved to callers of sys_setaffinity [was Processor sets (pset) for linux kernel 2.5/2.6?]
Date: Mon, 14 Apr 2003 23:40:08 +0100 [thread overview]
Message-ID: <200304142340.08276.srhaque@iee.org> (raw)
In-Reply-To: <1050146434.3e97f68300fff@netmail.pipex.net>
Hi,
Following up from http://www.ussg.iu.edu/hypermail/linux/kernel/0304.1/1113.html, here is a prototype patch against 2.5.67 to allow CPUs to be reserved to callers of sys_setaffinity(). It seems to work safely on a uniprocessor, and I'll test it on a multi-processor in a few days time. I'm not requesting inclusion of this patch until then.
Any feedback on form as well as content appreciated...I'm particularly wondering if it is worth stealing sys_setaffinity()/sys_getaffinity() for PID 0 to set/return this value since that would allow user-mode code to dynamically choose a non-restricted processor if required.
Thanks, Shaheed
1. The patch is against a clean 2.5.67
2. There is a new boot flag "restricted_cpus". This takes a bit mask of CPUs.
3. The initial task has it's cpus_allowed mask set to ~restricted_cpus in the fork initialisation code (it cannot be done in TASK_INIT since the value is not static). This should mean that any task that does not override cpus_allowed with sys_setaffinity does not get to run on the restricted processors.
4. The parsing of the boot flag does a sanity check to prevent all available CPUs being restricted.
5. Patch follows...
diff -urN -X dontdiff linux-2.5.67/kernel/fork.c newlinux-2.5.67/kernel/fork.c
--- linux-2.5.67/kernel/fork.c 2003-04-07 18:30:42.000000000 +0100
+++ newlinux-2.5.67/kernel/fork.c 2003-04-14 21:36:59.000000000 +0100
@@ -206,6 +206,7 @@
init_task.rlim[RLIMIT_NPROC].rlim_cur = max_threads/2;
init_task.rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
+ init_task.cpus_allowed = ~restricted_cpus;
}
static struct task_struct *dup_task_struct(struct task_struct *orig)
diff -urN -X dontdiff linux-2.5.67/kernel/sched.c newlinux-2.5.67/kernel/sched.c
--- linux-2.5.67/kernel/sched.c 2003-04-07 18:32:23.000000000 +0100
+++ newlinux-2.5.67/kernel/sched.c 2003-04-14 22:28:31.000000000 +0100
@@ -40,6 +40,13 @@
#endif
/*
+ * The boot flag "restricted_cpus" is negated to form the default per-task
+ * cpus_allowed mask. This has the effect of only allowing processes which
+ * call sys_setaffinity() to run on restricted_cpus.
+ */
+unsigned long restricted_cpus = 0;
+
+/*
* Convert user-nice values [ -20 ... 0 ... 19 ]
* to static priority [ MAX_RT_PRIO..MAX_PRIO-1 ],
* and back.
@@ -2338,6 +2345,34 @@
}
/*
+ * set_restricted_cpus - process boot flag to set restricted_cpus.
+ *
+ * NOTE: This function is a __setup and __init function.
+ */
+int __init set_restricted_cpus(char *options)
+{
+ unsigned long temp;
+ char *value;
+
+ if (!options || !*options)
+ return 0;
+ temp = simple_strtoul(value, &value, 0);
+
+ /*
+ * Make sure that the user has not restricted all available CPUs,
+ * otherwise a functioning system won't result!
+ */
+ if (~temp & cpu_online_map) {
+ restricted_cpus = temp;
+ } else {
+ printk(KERN_ERR "cannot restrict all 0x%lx online CPUs!\n", cpu_online_map);
+ }
+ return 0;
+}
+
+__setup("restricted_cpus=", set_restricted_cpus);
+
+/*
* migration_thread - this is a highprio system thread that performs
* thread migration by 'pulling' threads into the target runqueue.
*/
diff -urN -X dontdiff linux-2.5.67/Documentation/kernel-parameters.txt newlinux-2.5.67/Documentation/kernel-parameters.txt
--- linux-2.5.67/Documentation/kernel-parameters.txt 2003-04-07 18:33:03.000000000 +0100
+++ newlinux-2.5.67/Documentation/kernel-parameters.txt 2003-04-14 22:45:25.000000000 +0100
@@ -809,6 +809,10 @@
reserve= [KNL,BUGS] Force the kernel to ignore some iomem area
+ restricted_cpus=
+ [KNL] Don't use these CPUs for processes by default.
+ Format: <cpu_mask>
+
resume= [SWSUSP] Specify the partition device for software suspension
riscom8= [HW,SERIAL]
diff -urN -X dontdiff linux-2.5.67/include/linux/sched.h newlinux-2.5.67/include/linux/sched.h
--- linux-2.5.67/include/linux/sched.h 2003-04-07 18:30:42.000000000 +0100
+++ newlinux-2.5.67/include/linux/sched.h 2003-04-14 21:37:42.000000000 +0100
@@ -88,6 +88,7 @@
extern int nr_threads;
extern int last_pid;
+extern unsigned long restricted_cpus;
DECLARE_PER_CPU(unsigned long, process_counts);
extern int nr_processes(void);
extern unsigned long nr_running(void);
next prev parent reply other threads:[~2003-04-14 22:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-12 11:20 Processor sets (pset) for linux kernel 2.5/2.6? Shaheed R. Haque
2003-04-12 12:11 ` Dave Jones
2003-04-12 12:24 ` Antonio Vargas
2003-04-12 14:54 ` Martin J. Bligh
2003-04-12 18:23 ` Robert Love
2003-04-12 19:56 ` Shaheed R. Haque
2003-04-12 20:02 ` Robert Love
2003-04-13 8:30 ` Shaheed R. Haque
2003-04-13 14:28 ` Robert Love
2003-05-13 11:49 ` 2.6 must-fix list, v2 Shaheed R. Haque
2003-05-13 20:02 ` Andrew Morton
2003-05-13 22:46 ` Shaheed R. Haque
2003-05-14 2:42 ` Steven Cole
2003-05-14 11:49 ` Shaheed R. Haque
2003-05-14 13:08 ` Steven Cole
2003-05-13 22:49 ` Shaheed R. Haque
2003-05-14 11:02 ` Felipe Alfaro Solana
2003-05-14 15:59 ` Robert Love
2003-05-14 16:04 ` Robert Love
2003-05-14 21:01 ` shaheed
2003-05-14 21:15 ` Robert Love
2003-05-15 9:19 ` Shaheed R. Haque
2003-05-15 15:32 ` Robert Love
2003-05-15 20:07 ` shaheed
2003-05-15 20:20 ` Robert Love
2003-05-15 20:24 ` Robert Love
2003-05-15 21:30 ` shaheed
2003-04-13 3:52 ` Re: Processor sets (pset) for linux kernel 2.5/2.6? Martin J. Bligh
2003-07-15 11:39 ` [HOWTO] Emulate processor sets (pset) for linux kernel 2.5/2.6 \"shaheed r. haque\"
2003-04-14 22:40 ` shaheed [this message]
2003-05-01 20:19 ` Working .config for a Dell 2650 for 2.5.6x? (was Re: Processor sets (pset) for linux kernel 2.5/2.6?) shaheed
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=200304142340.08276.srhaque@iee.org \
--to=srhaque@iee.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox