: Option to run cache reap in thread mode

Hi,

In the process of testing per/cpu interrupt response times and CPU availability, I've found that running cache_reap() as a timer as is done currently results in some fairly long CPU holdoffs.

I would like to know what others think about running cache_reap() as a low priority realtime kthread, at least on certain cpus that would be configured that way (probably configured at boottime initially). I've been doing some testing running it this way on CPU's whose activity is mostly restricted to realtime work (requiring rapid response times).

Here's my first cut at an initial patch for this (there will be other changes later to set the configuration and to optimize locking in cache_reap()).

Dimitri Sivanich <[email protected]>

@@ -91,6 +91,9 @@
 #include	<linux/cpu.h>
 #include	<linux/sysctl.h>
 #include	<linux/module.h>
+#include	<linux/kthread.h>
+#include	<linux/stop_machine.h>
+#include	<linux/syscalls.h>
 
 #include	<asm/uaccess.h>
 #include	<asm/cacheflush.h>

@@ -530,8 +533,15 @@ enum {
 	FULL
 } g_cpucache_up;
 
+cpumask_t threaded_reap;	/* CPUs configured to run reap in thread mode */
+
+static DEFINE_PER_CPU(task_t *, reap_thread);
 static DEFINE_PER_CPU(struct timer_list, reap_timers);
 
+static void start_reap_thread(unsigned long cpu);
+#ifdef CONFIG_HOTPLUG_CPU
+static void stop_reap_thread(unsigned long cpu);
+#endif
 static void reap_timer_fnc(unsigned long data);
 static void free_block(kmem_cache_t* cachep, void** objpp, int len);
 static void enable_cpucache (kmem_cache_t *cachep);

@@ -661,11 +671,13 @@ static int __devinit cpuup_callback(stru
 		up(&cache_chain_sem);
 		break;
 	case CPU_ONLINE:
+		start_reap_thread(cpu);
 		start_cpu_timer(cpu);
 		break;
 #ifdef CONFIG_HOTPLUG_CPU
 	case CPU_DEAD:
 		stop_cpu_timer(cpu);
+		stop_reap_thread(cpu);
 		/* fall thru */
 	case CPU_UP_CANCELED:
 		down(&cache_chain_sem);

@@ -802,6 +814,9 @@ void __init kmem_cache_init(void)
 		up(&cache_chain_sem);
 	}
 
+	/* Initialize to run cache_reap as a timer on all cpus. */
+	cpus_clear(threaded_reap);
+
 	/* Done! */
 	g_cpucache_up = FULL;
 

@@ -2762,6 +2777,63 @@ next:
 	up(&cache_chain_sem);
 }
 
+/**
+ * If cache reap is run in thread mode, we run it from here.
+ */
+static int reap_thread(void * data)
+{
+	set_current_state(TASK_INTERRUPTIBLE);
+	while (!kthread_should_stop()) {
+		cache_reap();
+		schedule();
+		set_current_state(TASK_INTERRUPTIBLE);
+	}
+	__set_current_state(TASK_RUNNING);
+	return 0;
+}
+
+/**
+ * If the cpu is configured to run in thread mode, start the reap
+ * thread here.
+ */
+static void start_reap_thread(unsigned long cpu)
+{
+	task_t * p;
+	task_t ** rthread = &per_cpu(reap_thread, cpu);
+	struct sched_param param;
+
+	if (!cpu_isset(cpu, threaded_reap)) {
+		*rthread = NULL;
+		return;
+	}
+
+	param.sched_priority = sys_sched_get_priority_min(SCHED_FIFO); 
+
+	p = kthread_create(reap_thread, NULL, "cache_reap/%d",cpu);
+	if (IS_ERR(p))
+		return;
+	*rthread = p;
+	kthread_bind(p, cpu);
+	sys_sched_setscheduler(p->pid, SCHED_FIFO, &param);
+	wake_up_process(p);
+}
+
+/**
+ * If the cpu is running a reap thread, stop it here.
+ */
+#ifdef CONFIG_HOTPLUG_CPU
+static void stop_reap_thread(unsigned long cpu)
+{
+	task_t ** rthread = &per_cpu(reap_thread, cpu);
+
+	if (*rthread != NULL) {
+		kthread_stop(*rthread);
+		*rthread = NULL;
+	}
+
+}
+#endif
+
 /*
  * This is a timer handler.  There is one per CPU.  It is called periodially
  * to shrink this CPU's caches.  Otherwise there could be memory tied up

@@ -2770,10 +2842,16 @@ next:
 static void reap_timer_fnc(unsigned long cpu)
 {
 	struct timer_list *rt = &__get_cpu_var(reap_timers);
+	task_t *rthread = __get_cpu_var(reap_thread);
 
 	/* CPU hotplug can drag us off cpu: don't run on wrong CPU */
 	if (!cpu_is_offline(cpu)) {
-		cache_reap();
+		/* If we're not running in thread mode, simply run cache reap */
+		if (likely(rthread == NULL)) {
+			cache_reap();
+		} else {
+			wake_up_process(rthread);
+		}
 		mod_timer(rt, jiffies + REAPTIMEOUT_CPUC + cpu);
 	}
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

YAKT, sigh.. I don't quite understand what you mean with a "holdoff" so maybe you could explain what problem you see? You don't like cache_reap beeing called from timer context?

As for realtime stuff you're probably better off using something like rtlinux, getting into the hrt or even real strong soft rt busuniness means messing up the kernel horrible. Given you're @sgi.com address you probably know what a freaking mess and maintaince nightmare IRIX has become because of that.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

The issue(s) I'm attempting to solve is to achieve more deterministic interrupt response times on CPU's that have been designated for use as such. By setting cache_reap to run as a kthread, the cpu is only unavailable during the time that irq's are disabled. By doing this on a cpu that's been restricted from running most other processes, I have been able to achieve much more deterministic interrupt response times.

So yes, I don't want cache_reap to be called from timer context when I've configured a CPU as such.

Keep in mind that it's not like we're trying to achieve fast response times on all CPU's potentially running any number of processes.

Dimitri Sivanich <[email protected]>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Well, if you want deterministic interrupt latencies you should go for a realtime OS. I know Linux is the big thing in the industry, but you're really better off looking for a small Hard RT OS. From the OpenSource world eCOS or RTEMS come to mind. Or even rtlinux/rtai if you want to run a full linux kernel as idle task.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Although I don't want to see another kernel thread added as much as the next guy, I think that minimizing the amount of time that irqs are turned off is probably a good thing in general. For example, the patch to allow interrupts in spin_lock_irq if the lock is already taken is generally a really good thing, because even though reducing lock contention should be a goal, locks by their very nature are taken sometimes, and allowing other CPUs to get useful work done while they're waiting for it is obviously desirable.

Sure, for some applications, an RTOS is necessary. But it seems like keeping latencies down in Linux is a good thing to do nonetheless.

Can you think of other ways to reduce the length of time that interrupts are disabled during cache reaping? It seems like the cache_reap loop might be a candidate for reorganization (though that would probably imply other changes).

Thanks,
Jesse
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

I have another patch forthcoming that does some reorganizing of the locking. With the two patches I see substantial improvement.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi Chris,

I'm very curious about this comment - wondering what you base it on? I'm the engineering manager for IRIX real-time - we have no open bugs against it and have many customers depending on it. At least for the last 5 years had very low maintenance cost, mostly adding features, fixing a couple of bugs and producing new releases.

Perhaps you would be so kind to let me know what led you to your statement?

Thanks,

Lori Gilbertson

----
Lori A. Gilbertson
Mgr: CoreOS Development Group
Silicon Graphics, Inc. (SGI)
Email: [email protected]
Phone: 651-683-3433
Page: wwwmn.americas.sgi.com/~irixdev/os_core_sched/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Looks at the overhead of the normal IRIX sleeping locks vs linux spinlock (and the priority inversion and sleeping locks arguments are the next one I'll get from you I bet :)), talk to Jeremy how the HBA performance went down when he had to switch the drivers to the sleeping locks, look at the complexity of the irix scheduler with it's gazillions of special cases (and yes, I think the current Linux scheduler is already to complex), or the big mess with interrupt thread.

I've added Larry to the Cc list because he knows the IRIX internals much better than I do (or at least did once) and has been warning of this move that adds complexity to no end for all the special cases for at least five years. He also had some nice IRIX vs Linux benchmarks when Linux on Indys was new.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Before patching anything I want to understand what's going on in there. Please share your analysis.

How long?

How many objects?

Which slab?

Why?

Thanks.