Skip to contentSkip to conversation

Move cache_reap out of timer context

PATCH In review Dimitri Sivanich 3 participants 4 messages Jul 14, 2004 – Jul 28, 2004

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Move cache_reap out of timer context

I'm submitting two patches associated with moving cache_reap functionality out of timer context. Note that these patches do not make any further optimizations to cache_reap at this time.

The first patch adds a function similiar to schedule_delayed_work to allow work to be scheduled on another cpu.

The second patch makes use of schedule_delayed_work_on to schedule cache_reap to run from keventd.

These patches apply to 2.6.8-rc1.

include/linux/workqueue.h +2 -0
Index: linux/include/linux/workqueue.h
===================================================================
@@ -63,6 +63,8 @@
 
 extern int FASTCALL(schedule_work(struct work_struct *work));
 extern int FASTCALL(schedule_delayed_work(struct work_struct *work, unsigned long delay));
+
+extern int schedule_delayed_work_on(int cpu, struct work_struct *work, unsigned long delay);
 extern void flush_scheduled_work(void);
 extern int current_is_keventd(void);
 extern int keventd_up(void);
kernel/workqueue.c +20 -0
Index: linux/kernel/workqueue.c
===================================================================
@@ -398,6 +398,26 @@
 	return queue_delayed_work(keventd_wq, work, delay);
 }
 
+int schedule_delayed_work_on(int cpu,
+			struct work_struct *work, unsigned long delay)
+{
+	int ret = 0;
+	struct timer_list *timer = &work->timer;
+
+	if (!test_and_set_bit(0, &work->pending)) {
+		BUG_ON(timer_pending(timer));
+		BUG_ON(!list_empty(&work->entry));
+		/* This stores keventd_wq for the moment, for the timer_fn */
+		work->wq_data = keventd_wq;
+		timer->expires = jiffies + delay;
+		timer->data = (unsigned long)work;
+		timer->function = delayed_work_timer_fn;
+		add_timer_on(timer, cpu);
+		ret = 1;
+	}
+	return ret;
+}
+
 void flush_scheduled_work(void)
 {
 	flush_workqueue(keventd_wq);
mm/slab.c +23 -45

121 lines not on this page · raw message

--
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>

#1 lore raw
Quoted 7 lines · Dimitri Sivanich

I'm submitting two patches associated with moving cache_reap functionality out of timer context. Note that these patches do not make any further optimizations to cache_reap at this time.

The first patch adds a function similiar to schedule_delayed_work to allow work to be scheduled on another cpu.

Quoted 6 lines

The second patch makes use of schedule_delayed_work_on to schedule cache_reap to run from keventd.

These patches apply to 2.6.8-rc1.

looks good to me and i agree with moving this unbound execution-time function out of irq context. I suspect this should see some -mm testing first/too?

Ingo

#2 lore raw
Quoted 13 lines · Ingo Molnar
Quoted 10 lines · Dimitri Sivanich

I'm submitting two patches associated with moving cache_reap functionality out of timer context. Note that these patches do not make any further optimizations to cache_reap at this time.

The first patch adds a function similiar to schedule_delayed_work to allow work to be scheduled on another cpu.

The second patch makes use of schedule_delayed_work_on to schedule cache_reap to run from keventd.

Quoted 8 lines
Quoted 3 lines

These patches apply to 2.6.8-rc1.

looks good to me and i agree with moving this unbound execution-time function out of irq context. I suspect this should see some -mm testing first/too?

If others could test this patch on whatever platforms they have available, I would very much appreciate it.
--
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>

#3 lore raw
In reply to Dimitri Sivanich
Quoted 10 lines · Dimitri Sivanich

I'm submitting two patches associated with moving cache_reap functionality
out of timer context. Note that these patches do not make any further optimizations to cache_reap at this time.

The first patch adds a function similiar to schedule_delayed_work to allow work to be scheduled on another cpu.

The second patch makes use of schedule_delayed_work_on to schedule cache_reap to run from keventd.

It goes splat in cache_reap() if slab debugging is enabled, for rather obvious reasons:

#if DEBUG
	BUG_ON(!in_interrupt());
	BUG_ON(in_irq());

#endif

I've so far spent nearly two days just getting all the gunk people have sent in the last two weeks to compile properly. Heaven knows how long it'll take to test it. So I need somebody to grump at. So. Grump.

May I have the temerity to suggest that it would be more efficient if people were to test their own patches a bit more before sending them?

--
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>