[patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

[patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

[Remy Bohmer]

[-- Attachment #1: add-map-functionality-to-kernel-cmdline.patch --]
[-- Type: text/plain, Size: 3188 bytes --]

This patch adds a generic routine to the kernel, so that a map of
settings can be entered on the kernel commandline.

Signed-off-by: Remy Bohmer <linux@bohmer.net>

---
---
 include/linux/kernel.h |    1 
 lib/cmdline.c          |   58 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+)

Index: linux-2.6.24-rc5-rt1/include/linux/kernel.h
===================================================================
--- linux-2.6.24-rc5-rt1.orig/include/linux/kernel.h	2007-12-18 21:32:09.000000000 +0100
+++ linux-2.6.24-rc5-rt1/include/linux/kernel.h	2007-12-18 21:33:58.000000000 +0100
@@ -164,6 +164,7 @@ extern int vsscanf(const char *, const c
 
 extern int get_option(char **str, int *pint);
 extern char *get_options(const char *str, int nints, int *ints);
+extern int get_map_option(const char *str, const char *key, int *pint);
 extern unsigned long long memparse(char *ptr, char **retptr);
 
 extern int core_kernel_text(unsigned long addr);
Index: linux-2.6.24-rc5-rt1/lib/cmdline.c
===================================================================
--- linux-2.6.24-rc5-rt1.orig/lib/cmdline.c	2007-10-09 22:31:38.000000000 +0200
+++ linux-2.6.24-rc5-rt1/lib/cmdline.c	2007-12-18 21:33:58.000000000 +0100
@@ -15,6 +15,7 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/string.h>
+#include <asm/setup.h>
 
 /*
  *	If a hyphen was found in get_option, this will handle the
@@ -114,6 +115,63 @@ char *get_options(const char *str, int n
 }
 
 /**
+ *	get_map_option - Parse integer from an option map
+ *
+ *	This function parses an integer from an option map like
+ *           some_map=key1:99,key2:98,...,keyN:NN,NN
+ *	Only the value of the first match is returned, or if no
+ *	key option is given (key = NULL) the value of the first
+ *	field without a ':' is returned.
+ *
+ *	@str: option string
+ *	@key: The key inside the map, can be NULL
+ *	@pint: (output) integer value parsed from the map @str
+ *
+ *	Return values:
+ *	0 - no int in string
+ *	1 - int found
+ */
+int get_map_option(const char *str, const char *key, int *pint)
+{
+	char  buf[COMMAND_LINE_SIZE];
+	char  *p, *substr;
+	int   found = 0;
+
+	/* We must copy the string to the stack, because strsep()
+	   changes it.*/
+	strncpy(buf, str, COMMAND_LINE_SIZE);
+	buf[COMMAND_LINE_SIZE-1] = '\0';
+
+	p = buf;
+	substr = strsep(&p, ",");
+	while ((!found) && (substr != NULL)) {
+		if (strlen(substr) != 0) {
+			if (key == NULL) {
+				/* Check for the absence of any ':' */
+				if (strchr(substr, ':') == NULL) {
+					sscanf(substr, "%d", pint);
+					found = 1;
+				}
+			} else {
+				/* check if the first part of the key matches */
+				if (!strncmp(substr, key, strlen(key))) {
+					substr += strlen(key);
+					/* Now the next char must be a ':',
+					   if not, search for the next match */
+					if (*substr == ':') {
+						substr++;
+						sscanf(substr, "%d", pint);
+						found = 1;
+					}
+				}
+			}
+		}
+		substr = strsep(&p, ",");
+	}
+	return found;
+}
+
+/**
  *	memparse - parse a string with mem suffixes into a number
  *	@ptr: Where parse begins
  *	@retptr: (output) Pointer to next char after parse completes

-- 

Re: [patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

[Randy Dunlap]

On Wed, 19 Dec 2007 20:45:52 +0100 Remy Bohmer wrote:

> This patch adds a generic routine to the kernel, so that a map of
> settings can be entered on the kernel commandline.
> 
> Signed-off-by: Remy Bohmer <linux@bohmer.net>
> 
> ---
> ---
>  include/linux/kernel.h |    1 
>  lib/cmdline.c          |   58 +++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 59 insertions(+)
> 
> Index: linux-2.6.24-rc5-rt1/lib/cmdline.c
> ===================================================================
> --- linux-2.6.24-rc5-rt1.orig/lib/cmdline.c	2007-10-09 22:31:38.000000000 +0200
> +++ linux-2.6.24-rc5-rt1/lib/cmdline.c	2007-12-18 21:33:58.000000000 +0100
> @@ -114,6 +115,63 @@ char *get_options(const char *str, int n
>  }
>  
>  /**
> + *	get_map_option - Parse integer from an option map

The @param lines (below) need to go here, immediately following the
function short description (the line above).  No intervening blank
lines.

> + *
> + *	This function parses an integer from an option map like
> + *           some_map=key1:99,key2:98,...,keyN:NN,NN
> + *	Only the value of the first match is returned, or if no
> + *	key option is given (key = NULL) the value of the first
> + *	field without a ':' is returned.
> + *
> + *	@str: option string
> + *	@key: The key inside the map, can be NULL
> + *	@pint: (output) integer value parsed from the map @str
> + *
> + *	Return values:
> + *	0 - no int in string
> + *	1 - int found
> + */
> +int get_map_option(const char *str, const char *key, int *pint)
> +{
> +	char  buf[COMMAND_LINE_SIZE];

COMMAND_LINE_SIZE varies from 256 to 2048, depending on $ARCH.
That's a bit too much to declare on a function's local stack --
unless you are very certain of the call tree to this point and
that the total stack size is safe.  Can you just kmalloc() this
buf?

> +	char  *p, *substr;
> +	int   found = 0;
> +
> +	/* We must copy the string to the stack, because strsep()
> +	   changes it.*/
> +	strncpy(buf, str, COMMAND_LINE_SIZE);
> +	buf[COMMAND_LINE_SIZE-1] = '\0';
> +
> +	p = buf;
> +	substr = strsep(&p, ",");
> +	while ((!found) && (substr != NULL)) {
> +		if (strlen(substr) != 0) {
> +			if (key == NULL) {
> +				/* Check for the absence of any ':' */
> +				if (strchr(substr, ':') == NULL) {
> +					sscanf(substr, "%d", pint);
> +					found = 1;
> +				}
> +			} else {
> +				/* check if the first part of the key matches */
> +				if (!strncmp(substr, key, strlen(key))) {
> +					substr += strlen(key);
> +					/* Now the next char must be a ':',
> +					   if not, search for the next match */
> +					if (*substr == ':') {
> +						substr++;
> +						sscanf(substr, "%d", pint);
> +						found = 1;
> +					}
> +				}
> +			}
> +		}
> +		substr = strsep(&p, ",");
> +	}
> +	return found;
> +}

---
~Randy

Re: [patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

[Remy Bohmer]

Hello Randy,

Sorry for the language errors, English is not my Native language, so I
make these stupid errors...

> > + *   get_map_option - Parse integer from an option map
> The @param lines (below) need to go here, immediately following the
> function short description (the line above).  No intervening blank
> lines.

OK, I will adapt that.

> > +int get_map_option(const char *str, const char *key, int *pint)
> > +{
> > +     char  buf[COMMAND_LINE_SIZE];
>
> COMMAND_LINE_SIZE varies from 256 to 2048, depending on $ARCH.
> That's a bit too much to declare on a function's local stack --
> unless you are very certain of the call tree to this point and
> that the total stack size is safe.  Can you just kmalloc() this
> buf?

I know it is big on a 4k stack, and I also think it is not very nice...
But kmalloc() panics the kernel if I do it as soon as in the __setup() code.

The problem is that the original string may not be modified by the
cmdline-parser, and I do not know the length of the command up front,
(except that it cannot be longer than this define). Allocating a
global buffer is not safe and needs locking. So actually only what
left for me was the stack... or rewrite the used C-library-routines
completely myself, for this purpose only, which is also not nice.

I hope someone could point to me to another possibilty, that I did not
think of yet.


Kind Regards,

Remy

>
> > +     char  *p, *substr;
> > +     int   found = 0;
> > +
> > +     /* We must copy the string to the stack, because strsep()
> > +        changes it.*/
> > +     strncpy(buf, str, COMMAND_LINE_SIZE);
> > +     buf[COMMAND_LINE_SIZE-1] = '\0';
> > +
> > +     p = buf;
> > +     substr = strsep(&p, ",");
> > +     while ((!found) && (substr != NULL)) {
> > +             if (strlen(substr) != 0) {
> > +                     if (key == NULL) {
> > +                             /* Check for the absence of any ':' */
> > +                             if (strchr(substr, ':') == NULL) {
> > +                                     sscanf(substr, "%d", pint);
> > +                                     found = 1;
> > +                             }
> > +                     } else {
> > +                             /* check if the first part of the key matches */
> > +                             if (!strncmp(substr, key, strlen(key))) {
> > +                                     substr += strlen(key);
> > +                                     /* Now the next char must be a ':',
> > +                                        if not, search for the next match */
> > +                                     if (*substr == ':') {
> > +                                             substr++;
> > +                                             sscanf(substr, "%d", pint);
> > +                                             found = 1;
> > +                                     }
> > +                             }
> > +                     }
> > +             }
> > +             substr = strsep(&p, ",");
> > +     }
> > +     return found;
> > +}
>
> ---
> ~Randy
>

[patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline (repost:CC to LKML)

[Remy Bohmer]

[-- Attachment #1: changing_interrupt_prios_from_kernel_cmdline.patch --]
[-- Type: text/plain, Size: 7917 bytes --]

The RT-patch originally creates all its IRQ-threads at priority 50.
Of course, this is not a usable default for many realtime systems
and therefor these priorities has to be tuneable for each RT-system.
But, currently there is no way within the kernel to adjust this to
the needs of the user. Some scripts are floating around to do this
from userspace, but for several applications the priorities should
already be set properly by the kernel itself before userland is
started.

This patch changes this by adding a kernel cmd-line option that can
handle a map of priorities.
It is based on the name of the driver that requests an interrupt, it
does NOT use the IRQ-ID to prioritize a certain IRQ thread.
This is designed this way because across several hardware-boards the
IRQ-IDs can change, but not necessarily the drivers 
(interrupt handlers) name.


Remarks:
* There is a check for conflicts added, for situations where 
  IRQ-sharing is detected with different priorities requested
  on the kernel cmd-line.
* Priorities are only set at creation time of the IRQ-thread.
* If userland overrules, it is NOT restored by this code.
* if no new kernel cmdline options are given, the kernel works
  as before, and all IRQ-threads start at 50.
* No wildcards are supported on the cmdline.

See kernel/Documentation/kernel-parameters.txt for usage info.

Signed-off-by: Remy Bohmer <linux@bohmer.net>

---
 Documentation/kernel-parameters.txt |    7 ++
 include/linux/irq.h                 |    1 
 kernel/irq/manage.c                 |  101 ++++++++++++++++++++++++++++++++----
 3 files changed, 98 insertions(+), 11 deletions(-)

Index: linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.24-rc5-rt1.orig/Documentation/kernel-parameters.txt	2007-12-18 22:09:13.000000000 +0100
+++ linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt	2007-12-18 22:09:16.000000000 +0100
@@ -799,6 +799,13 @@ and is between 256 and 4096 characters. 
 	ips=		[HW,SCSI] Adaptec / IBM ServeRAID controller
 			See header of drivers/scsi/ips.c.
 
+	irq_pmap=	[IRQ-threading] List of priorities each interrupt
+			thread must have.
+			Format: irq_pmap=megasas:90,eth0:40,50
+			The first field without ':', is the default prio.
+			If this cmdline argument is ommitted, every thread
+			runs at prio 50.
+
 	ports=		[IP_VS_FTP] IPVS ftp helper module
 			Default is 21.
 			Up to 8 (IP_VS_APP_MAX_PORTS) ports
Index: linux-2.6.24-rc5-rt1/include/linux/irq.h
===================================================================
--- linux-2.6.24-rc5-rt1.orig/include/linux/irq.h	2007-12-18 22:09:13.000000000 +0100
+++ linux-2.6.24-rc5-rt1/include/linux/irq.h	2007-12-18 22:09:16.000000000 +0100
@@ -169,6 +169,7 @@ struct irq_desc {
 	unsigned int		irqs_unhandled;
 	unsigned long		last_unhandled;	/* Aging timer for unhandled count */
 	struct task_struct	*thread;
+	int                     rt_prio;
 	wait_queue_head_t	wait_for_handler;
 	cycles_t		timestamp;
 	raw_spinlock_t		lock;
Index: linux-2.6.24-rc5-rt1/kernel/irq/manage.c
===================================================================
--- linux-2.6.24-rc5-rt1.orig/kernel/irq/manage.c	2007-12-18 22:09:13.000000000 +0100
+++ linux-2.6.24-rc5-rt1/kernel/irq/manage.c	2007-12-18 22:15:43.000000000 +0100
@@ -13,9 +13,19 @@
 #include <linux/kthread.h>
 #include <linux/syscalls.h>
 #include <linux/interrupt.h>
+#include <linux/list.h>
 
 #include "internals.h"
 
+
+#ifdef CONFIG_PREEMPT_HARDIRQS
+
+static char *cmdline;
+static int  default_prio = MAX_USER_RT_PRIO/2;
+
+#endif
+
+
 #ifdef CONFIG_SMP
 
 /**
@@ -260,7 +270,7 @@ void recalculate_desc_flags(struct irq_d
 			desc->status |= IRQ_NODELAY;
 }
 
-static int start_irq_thread(int irq, struct irq_desc *desc);
+static int start_irq_thread(int irq, struct irq_desc *desc, int prio);
 
 /*
  * Internal function that tells the architecture code whether a
@@ -293,6 +303,8 @@ void compat_irq_chip_set_default_handler
 		desc->handle_irq = NULL;
 }
 
+static int get_irq_prio(const char *name);
+
 /*
  * Internal function to register an irqaction - typically used to
  * allocate special interrupts that are part of the architecture.
@@ -328,7 +340,7 @@ int setup_irq(unsigned int irq, struct i
 	}
 
 	if (!(new->flags & IRQF_NODELAY))
-		if (start_irq_thread(irq, desc))
+		if (start_irq_thread(irq, desc, get_irq_prio(new->name)))
 			return -ENOMEM;
 	/*
 	 * The following block of code has to be executed atomically
@@ -811,11 +823,7 @@ static int do_irqd(void * __desc)
 #endif
 	current->flags |= PF_NOFREEZE | PF_HARDIRQ;
 
-	/*
-	 * Set irq thread priority to SCHED_FIFO/50:
-	 */
-	param.sched_priority = MAX_USER_RT_PRIO/2;
-
+	param.sched_priority = desc->rt_prio;
 	sys_sched_setscheduler(current->pid, SCHED_FIFO, &param);
 
 	while (!kthread_should_stop()) {
@@ -850,11 +858,20 @@ static int do_irqd(void * __desc)
 
 static int ok_to_create_irq_threads;
 
-static int start_irq_thread(int irq, struct irq_desc *desc)
+static int start_irq_thread(int irq, struct irq_desc *desc, int prio)
 {
-	if (desc->thread || !ok_to_create_irq_threads)
+	if (!ok_to_create_irq_threads)
 		return 0;
 
+	if (desc->thread) {
+		if (desc->rt_prio != prio)
+			printk(KERN_NOTICE
+			       "irqd: Interrupt sharing detected with "
+			       "conflicting thread priorities, irq:%d!\n", irq);
+		return 0;
+	}
+
+	desc->rt_prio = prio;
 	desc->thread = kthread_create(do_irqd, desc, "IRQ-%d", irq);
 	if (!desc->thread) {
 		printk(KERN_ERR "irqd: could not create IRQ thread %d!\n", irq);
@@ -881,13 +898,13 @@ void __init init_hardirqs(void)
 		irq_desc_t *desc = irq_desc + i;
 
 		if (desc->action && !(desc->status & IRQ_NODELAY))
-			start_irq_thread(i, desc);
+			start_irq_thread(i, desc, get_irq_prio(NULL));
 	}
 }
 
 #else
 
-static int start_irq_thread(int irq, struct irq_desc *desc)
+static int start_irq_thread(int irq, struct irq_desc *desc, int prio)
 {
 	return 0;
 }
@@ -901,3 +918,65 @@ void __init early_init_hardirqs(void)
 	for (i = 0; i < NR_IRQS; i++)
 		init_waitqueue_head(&irq_desc[i].wait_for_handler);
 }
+
+#ifdef CONFIG_PREEMPT_HARDIRQS
+
+/*
+ * Lookup the interrupt thread priority
+ * A map for the priorities can be given on the kernel commandline.
+ * if name is NULL, or no kernel commandline options is given, the default
+ * prio is used, which is either MAX_PRIO/2, or the default given on the
+ * kernel commandline.
+ */
+static int get_irq_prio(const char *name)
+{
+	int prio = default_prio; /* Set the default for all threads */
+
+	/* If no commandline options, use thread prio defaults the old style.*/
+	if (!cmdline)
+		return prio;
+
+	if (!get_map_option(cmdline, name, &prio)) {
+		prio = default_prio;
+		if (name != NULL)
+			printk(KERN_INFO
+				"No IRQ-priority specified for '%s', " \
+				"using default(=%d)\n", name, prio);
+	} else {
+		if ((prio <= 0) || (prio >= MAX_USER_RT_PRIO))
+			prio = default_prio;
+
+		if (name != NULL)
+			printk(KERN_INFO "Using IRQ-priority %d for '%s'\n",
+				prio, name);
+	}
+	return prio;
+}
+
+/*
+ * Store the pointer to the arguments in a global var, and store the
+ * default prio globally
+ */
+static int __init irq_prio_map_setup(char *str)
+{
+	if (!str) /* sanity check */
+		return 1;
+
+	cmdline		= str; /* store it for later use */
+	default_prio	= get_irq_prio(NULL);
+
+	printk(KERN_INFO "Default IRQ-priority: %d\n", default_prio);
+	return 1;
+}
+
+/*
+ * The commandline looks like this: irq_pmap=megasas:90,eth0:40,50
+ * The first field without the ':' is used as the default for all irq-threads.
+ * There is a check for conflicts on irq-sharing.
+ * The priorities are only set on creation of the interrupt threads, thus at
+ * the time a driver uses a certain interrupt thread for the first time.
+ * Unknown or redundant fields are ignored.
+ */
+__setup("irq_pmap=", irq_prio_map_setup);
+
+#endif

-- 

Re: [patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline (repost:CC to LKML)

[Randy Dunlap]

On Wed, 19 Dec 2007 20:45:53 +0100 Remy Bohmer wrote:

>  Documentation/kernel-parameters.txt |    7 ++
>  include/linux/irq.h                 |    1 
>  kernel/irq/manage.c                 |  101 ++++++++++++++++++++++++++++++++----
>  3 files changed, 98 insertions(+), 11 deletions(-)
> 
> Index: linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt
> ===================================================================
> --- linux-2.6.24-rc5-rt1.orig/Documentation/kernel-parameters.txt	2007-12-18 22:09:13.000000000 +0100
> +++ linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt	2007-12-18 22:09:16.000000000 +0100
> @@ -799,6 +799,13 @@ and is between 256 and 4096 characters. 
>  	ips=		[HW,SCSI] Adaptec / IBM ServeRAID controller
>  			See header of drivers/scsi/ips.c.
>  
> +	irq_pmap=	[IRQ-threading] List of priorities each interrupt
> +			thread must have.
> +			Format: irq_pmap=megasas:90,eth0:40,50
> +			The first field without ':', is the default prio.

	Drop comma.

> +			If this cmdline argument is ommitted, every thread

                                                    omitted,

> +			runs at prio 50.
> +
>  	ports=		[IP_VS_FTP] IPVS ftp helper module
>  			Default is 21.
>  			Up to 8 (IP_VS_APP_MAX_PORTS) ports

> Index: linux-2.6.24-rc5-rt1/kernel/irq/manage.c
> ===================================================================
> --- linux-2.6.24-rc5-rt1.orig/kernel/irq/manage.c	2007-12-18 22:09:13.000000000 +0100
> +++ linux-2.6.24-rc5-rt1/kernel/irq/manage.c	2007-12-18 22:15:43.000000000 +0100

> @@ -901,3 +918,65 @@ void __init early_init_hardirqs(void)
>  	for (i = 0; i < NR_IRQS; i++)
>  		init_waitqueue_head(&irq_desc[i].wait_for_handler);
>  }
> +
> +#ifdef CONFIG_PREEMPT_HARDIRQS
> +
> +/*
> + * Lookup the interrupt thread priority
> + * A map for the priorities can be given on the kernel commandline.
> + * if name is NULL, or no kernel commandline options is given, the default

      If ...................................... option is given,

> + * prio is used, which is either MAX_PRIO/2, or the default given on the
> + * kernel commandline.
> + */
> +static int get_irq_prio(const char *name)
> +{


---
~Randy

Re: [patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline (repost:CC to LKML)

[Jaswinder Singh]

On 12/20/07, Remy Bohmer <linux@bohmer.net> wrote:
>  	struct task_struct	*thread;
> +	int                     rt_prio;
>  	wait_queue_head_t	wait_for_handler;

int rt_prio or unsigned int rt_prio, which one is better.

Thank you,

Jaswinder SIngh.

[patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Remy Bohmer]

[-- Attachment #1: changing_softirq_prios_from_kernel_cmdline.patch --]
[-- Type: text/plain, Size: 6493 bytes --]

The RT-patch originally creates all its softirq-threads at
priority 50. Of course, this is not a usable default for many
realtime systems and therefor these priorities has to be tuneable
for each RT-system. But, currently there is no way within the
kernel to adjust this to the needs of the user. Some scripts
are floating around to do this from userspace, but for several
applications the priorities should already be set properly by
the kernel itself before userland is started.

This patch changes this by adding a kernel cmd-line option that
can handle a map of priorities.

Remarks:
* Priorities are only set at creation time of the softirq.
* Priorities has to be set per-cpu.
* If userland overrules, it is NOT restored by this code.
* if no new kernel cmdline options are given, the kernel works
  as before, and all softirqs start at 50.
* No wildcards are supported on the cmdline.

See kernel/Documentation/kernel-parameters.txt for usage info.

Signed-off-by: Remy Bohmer <linux@bohmer.net>

---
 Documentation/kernel-parameters.txt |   11 +++
 kernel/softirq.c                    |  105 ++++++++++++++++++++++++++++++------
 2 files changed, 99 insertions(+), 17 deletions(-)

Index: linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.24-rc5-rt1.orig/Documentation/kernel-parameters.txt	2007-12-18 22:06:11.000000000 +0100
+++ linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt	2007-12-18 22:07:19.000000000 +0100
@@ -806,6 +806,17 @@ and is between 256 and 4096 characters. 
 			If this cmdline argument is ommitted, every thread
 			runs at prio 50.
 
+	sirq_pmap=	[IRQ-threading] List of priorities each softirq
+			thread must have.
+			Format: sirq_pmap=block/0:90,sched/0:75,50
+			The priorities have to be specified per-cpu.
+			The first field without ':', is the default prio.
+			The names have to match the softirq_names[] table in
+			kernel/softirq.c, (thus without 'softirq-' prefix) to
+			keep the cmd-line short.
+			If this cmdline argument is ommitted, every softirq
+			runs at prio 50.
+
 	ports=		[IP_VS_FTP] IPVS ftp helper module
 			Default is 21.
 			Up to 8 (IP_VS_APP_MAX_PORTS) ports
Index: linux-2.6.24-rc5-rt1/kernel/softirq.c
===================================================================
--- linux-2.6.24-rc5-rt1.orig/kernel/softirq.c	2007-12-18 22:06:11.000000000 +0100
+++ linux-2.6.24-rc5-rt1/kernel/softirq.c	2007-12-18 22:08:54.000000000 +0100
@@ -66,6 +66,10 @@ struct softirqdata {
 
 static DEFINE_PER_CPU(struct softirqdata [MAX_SOFTIRQ], ksoftirqd);
 
+static char *cmdline;
+static int  default_prio = MAX_USER_RT_PRIO/2;
+
+
 #ifdef CONFIG_PREEMPT_SOFTIRQS
 /*
  * Preempting the softirq causes cases that would not be a
@@ -770,10 +774,28 @@ EXPORT_SYMBOL(tasklet_unlock_wait);
 
 #endif
 
+static const char *softirq_names [] =
+{
+  [HI_SOFTIRQ]		= "high",
+  [SCHED_SOFTIRQ]	= "sched",
+  [TIMER_SOFTIRQ]	= "timer",
+  [NET_TX_SOFTIRQ]	= "net-tx",
+  [NET_RX_SOFTIRQ]	= "net-rx",
+  [BLOCK_SOFTIRQ]	= "block",
+  [TASKLET_SOFTIRQ]	= "tasklet",
+#ifdef CONFIG_HIGH_RES_TIMERS
+  [HRTIMER_SOFTIRQ]	= "hrtimer",
+#endif
+  [RCU_SOFTIRQ]		= "rcu",
+};
+
+static int get_softirq_prio(const char *name);
+
 static int ksoftirqd(void * __data)
 {
-	struct sched_param param = { .sched_priority = MAX_USER_RT_PRIO/2 };
+	struct sched_param param = { 0, };
 	struct softirqdata *data = __data;
+	char buf[50];
 	u32 softirq_mask = (1 << data->nr);
 	struct softirq_action *h;
 	int cpu = data->cpu;
@@ -781,8 +803,12 @@ static int ksoftirqd(void * __data)
 #ifdef CONFIG_PREEMPT_SOFTIRQS
 	init_waitqueue_head(&data->wait);
 #endif
-
+	/* Lookup the priority of this softirq, and set the prio accordingly */
+	snprintf(buf, sizeof(buf), "%s/%lu",
+		 softirq_names[data->nr], data->cpu);
+	param.sched_priority = get_softirq_prio(buf);
 	sys_sched_setscheduler(current->pid, SCHED_FIFO, &param);
+
 	current->flags |= PF_SOFTIRQ;
 	set_current_state(TASK_INTERRUPTIBLE);
 
@@ -911,21 +937,6 @@ void takeover_tasklets(unsigned int cpu)
 }
 #endif /* CONFIG_HOTPLUG_CPU */
 
-static const char *softirq_names [] =
-{
-  [HI_SOFTIRQ]		= "high",
-  [SCHED_SOFTIRQ]	= "sched",
-  [TIMER_SOFTIRQ]	= "timer",
-  [NET_TX_SOFTIRQ]	= "net-tx",
-  [NET_RX_SOFTIRQ]	= "net-rx",
-  [BLOCK_SOFTIRQ]	= "block",
-  [TASKLET_SOFTIRQ]	= "tasklet",
-#ifdef CONFIG_HIGH_RES_TIMERS
-  [HRTIMER_SOFTIRQ]	= "hrtimer",
-#endif
-  [RCU_SOFTIRQ]		= "rcu",
-};
-
 static int __cpuinit cpu_callback(struct notifier_block *nfb,
 				  unsigned long action,
 				  void *hcpu)
@@ -1051,3 +1062,63 @@ int on_each_cpu(void (*func) (void *info
 }
 EXPORT_SYMBOL(on_each_cpu);
 #endif
+
+/*
+ * Lookup the softirq thread priority.
+ * A map for the priorities can be given on the kernel commandline.
+ * if name is NULL, or no kernel commandline options is given, the default
+ * prio is returned, which is either MAX_PRIO/2, or the default given on the
+ * kernel commandline.
+ */
+static int get_softirq_prio(const char *name)
+{
+	int prio = default_prio; /* Set the default for all threads */
+
+	/* If no commandline options, use thread prio defaults the old style.*/
+	if (!cmdline)
+		return prio;
+
+	if (!get_map_option(cmdline, name, &prio)) {
+		prio = default_prio;
+		if (name != NULL)
+			printk(KERN_INFO
+				"No priority specified for 'softirq-%s', " \
+				"using default(=%d)\n", name, prio);
+	} else {
+		if ((prio <= 0) || (prio >= MAX_USER_RT_PRIO))
+			prio = default_prio;
+
+		if (name != NULL)
+			printk(KERN_INFO "Using priority %d for 'softirq-%s'\n",
+				prio, name);
+	}
+	return prio;
+}
+
+/*
+ * Store the pointer to the arguments in a global var, and store the
+ * default prio globally
+ */
+static int __init softirq_prio_map_setup(char *str)
+{
+	if (!str) /* sanity check */
+		return 1;
+
+	cmdline		= str; /* store it for later use */
+	default_prio	= get_softirq_prio(NULL);
+
+	printk(KERN_INFO "Default softirq priority: %d\n", default_prio);
+
+	return 1;
+}
+
+/*
+ * The commandline looks like this:
+ *                 sirq_pmap=block/0:90,sched/0:75,50
+ * The first field without the ':' is used as the default for all
+ * soft-irq-threads. The priorities are only set on creation of the
+ * softirq threads. Unknown or redundant fields are ignored.
+ * The names have to match the softirq_names[] table without 'softirq-' prefix
+ * to keep the cmd-line short.
+ */
+__setup("sirq_pmap=", softirq_prio_map_setup);

-- 

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Randy Dunlap]

On Wed, 19 Dec 2007 20:45:54 +0100 Remy Bohmer wrote:

>  Documentation/kernel-parameters.txt |   11 +++
>  kernel/softirq.c                    |  105 ++++++++++++++++++++++++++++++------
>  2 files changed, 99 insertions(+), 17 deletions(-)
> 
> Index: linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt
> ===================================================================
> --- linux-2.6.24-rc5-rt1.orig/Documentation/kernel-parameters.txt	2007-12-18 22:06:11.000000000 +0100
> +++ linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt	2007-12-18 22:07:19.000000000 +0100
> @@ -806,6 +806,17 @@ and is between 256 and 4096 characters. 
>  			If this cmdline argument is ommitted, every thread
>  			runs at prio 50.
>  
> +	sirq_pmap=	[IRQ-threading] List of priorities each softirq
> +			thread must have.
> +			Format: sirq_pmap=block/0:90,sched/0:75,50
> +			The priorities have to be specified per-cpu.
> +			The first field without ':', is the default prio.

	Drop comma.

> +			The names have to match the softirq_names[] table in
> +			kernel/softirq.c, (thus without 'softirq-' prefix) to
> +			keep the cmd-line short.
> +			If this cmdline argument is ommitted, every softirq

                                                    omitted,

> +			runs at prio 50.
> +
>  	ports=		[IP_VS_FTP] IPVS ftp helper module
>  			Default is 21.
>  			Up to 8 (IP_VS_APP_MAX_PORTS) ports
> Index: linux-2.6.24-rc5-rt1/kernel/softirq.c
> ===================================================================
> --- linux-2.6.24-rc5-rt1.orig/kernel/softirq.c	2007-12-18 22:06:11.000000000 +0100
> +++ linux-2.6.24-rc5-rt1/kernel/softirq.c	2007-12-18 22:08:54.000000000 +0100
> @@ -1051,3 +1062,63 @@ int on_each_cpu(void (*func) (void *info
>  }
>  EXPORT_SYMBOL(on_each_cpu);
>  #endif
> +
> +/*
> + * Lookup the softirq thread priority.
> + * A map for the priorities can be given on the kernel commandline.
> + * if name is NULL, or no kernel commandline options is given, the default

      If ...................................... option is given,

> + * prio is returned, which is either MAX_PRIO/2, or the default given on the
> + * kernel commandline.
> + */
> +static int get_softirq_prio(const char *name)
> +{
...
> +}

---
~Randy

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

On 12/20/07, Remy Bohmer <linux@bohmer.net> wrote:
> The RT-patch originally creates all its softirq-threads at
> priority 50.

Is it possible to run softirq-threads or IRQs as a non-realtime tasks
in RT kernel.

If yes, then how.

Thank you,

Jaswinder Singh.

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Remy Bohmer]

Hello Jaswinder,

> Is it possible to run softirq-threads or IRQs as a non-realtime tasks
> in RT kernel.

Currently the answer is no. (Unless overruled from userspace) I did
not take this requirement into account.
So, Is this a serious requirement? Should this be possible?
I cannot imagine a purpose in which that is wanted, it would cause
unpredictable interrupt handling, and I can imagine that many
drivers/devices will not like that.

The purpose is usually to spread the threads across several
priorities, to create room for some RT-process to become more
important than an IRQ that generates large latencies, and each
RT-system designer shall divide the priorities different, due to
different system requirements.

Kind Regards,

Remy

2007/12/20, Jaswinder Singh <jaswinderlinuxrt@gmail.com>:
> On 12/20/07, Remy Bohmer <linux@bohmer.net> wrote:
> > The RT-patch originally creates all its softirq-threads at
> > priority 50.
>
> Is it possible to run softirq-threads or IRQs as a non-realtime tasks
> in RT kernel.
>
> If yes, then how.
>
> Thank you,
>
> Jaswinder Singh.
>

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

Hello Remy,

On 12/20/07, Remy Bohmer <linux@bohmer.net> wrote:
> So, Is this a serious requirement? Should this be possible?

I have noticed this problem:
root@192.168.1.253:~# cat /proc/loadavgrt
1.00 1.00 1.00 0/52 1158
root@192.168.1.253:~# cat /proc/loadavg
0.00 0.00 0.02 1/52 1159
root@192.168.1.253:~#

So I am curious, if possible, user can switch softirq-threads or IRQs
RT tasks to non-RT tasks for slow hardware or least important hardware
for NON-RT tasks. So this will improve RT behaviour.

By default, all softirq-threads or IRQs will be RT task but if there
is some option user can switch it to NON-RT task then it will be good.

Thank you,

Jaswinder Singh.

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Remy Bohmer]

> By default, all softirq-threads or IRQs will be RT task but if there
> is some option user can switch it to NON-RT task then it will be good.

Okay, understood.
I will think about how to add that too. But, probably we can add it
seperately from this patchset.

Kind Regards,

Remy


2007/12/20, Jaswinder Singh <jaswinderlinuxrt@gmail.com>:
> Hello Remy,
>
> On 12/20/07, Remy Bohmer <linux@bohmer.net> wrote:
> > So, Is this a serious requirement? Should this be possible?
>
> I have noticed this problem:
> root@192.168.1.253:~# cat /proc/loadavgrt
> 1.00 1.00 1.00 0/52 1158
> root@192.168.1.253:~# cat /proc/loadavg
> 0.00 0.00 0.02 1/52 1159
> root@192.168.1.253:~#
>
> So I am curious, if possible, user can switch softirq-threads or IRQs
> RT tasks to non-RT tasks for slow hardware or least important hardware
> for NON-RT tasks. So this will improve RT behaviour.
>
> By default, all softirq-threads or IRQs will be RT task but if there
> is some option user can switch it to NON-RT task then it will be good.
>
> Thank you,
>
> Jaswinder Singh.
>

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Juergen Beisert]

On Thursday 20 December 2007 13:45, Jaswinder Singh wrote:
> On 12/20/07, Remy Bohmer <linux@bohmer.net> wrote:
> > So, Is this a serious requirement? Should this be possible?
>
> I have noticed this problem:
> root@192.168.1.253:~# cat /proc/loadavgrt
> 1.00 1.00 1.00 0/52 1158
> root@192.168.1.253:~# cat /proc/loadavg
> 0.00 0.00 0.02 1/52 1159
> root@192.168.1.253:~#
>
> So I am curious, if possible, user can switch softirq-threads or IRQs
> RT tasks to non-RT tasks for slow hardware or least important hardware
> for NON-RT tasks. So this will improve RT behaviour.
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why?

IMHO: Simply decrease the RT priority of less important IRQs or increase all 
other more important IRQs. IRQs are always more important than other 
processes in a system, also in non RT systems.

Juergen
-- 
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
         Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

hello Juergen,

On 12/20/07, Juergen Beisert <jbe@pengutronix.de> wrote:
> On Thursday 20 December 2007 13:45, Jaswinder Singh wrote:
> > So I am curious, if possible, user can switch softirq-threads or IRQs
> > RT tasks to non-RT tasks for slow hardware or least important hardware
> > for NON-RT tasks. So this will improve RT behaviour.
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Why?
>
> IMHO: Simply decrease the RT priority of less important IRQs or increase all
> other more important IRQs. IRQs are always more important than other
> processes in a system, also in non RT systems.
>

In RT Kernel we have :-
RT Tasks and Non-RT tasks.

So we can also support :-
RT softirq-threads/IRQs and non-RT softirq-threads/IRQs

So RT softirq-threads/IRQs for RT Tasks
and non-RT softirq-threads/IRQs for non-RT Tasks.

OR also remove Non-RT tasks from RT Kernel and simply decrease the RT
priority of less important task as per your suggestions.

Thank you,

Jaswinder Singh.

> Juergen
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
>  Pengutronix - Linux Solutions for Science and Industry
>     Handelsregister: Amtsgericht Hildesheim, HRA 2686
>          Vertretung Sued/Muenchen, Germany
>    Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9
>