[patch] PPC/PPC64 port of voluntary preempt patch

[patch] PPC/PPC64 port of voluntary preempt patch

[Scott Wood]

I have attached a port of the voluntary preempt patch to PPC and
PPC64.  The patch is against P7, but it applies against P8 as well.

I've tested it on a dual G5 Mac, both in uniprocessor and SMP.

Some notes on changes to the generic part of the patch/existing
generic code:

	I changed the generic code so that request_irq() prior to the
	scheduler being ready to run.  Previously, if this happened,
	it'd try to spawn a thread anyway, and oops.
	
	I changed the no-op definitions of voluntary_resched() and such
	to be empty inline functions, rather than #defined to 0.  When 0
	is used, newer GCCs (I'm using 3.4.1) issue a warning about
	statements with no effect.  Due to this, I removed the redundant
	definition of voluntary_resched() from sched.h (it's also in
	kernel.h, which is always included by sched.h).  Does it need to
	be in kernel.h?
	
	The WARN_ON(system_state == SYSTEM_BOOTING) was flooding me
	with warnings; this stopped when I moved the setting of
	system_state before the init thread was started (it seems
	rather odd that one would not be able to schedule when creating
	a thread...).
	
	The latency tracker at one point used cpu_khz/1000, and at another
	used cpu_khz/1024.  Is there a reason why cycles_to_usecs isn't
	used in both places?
	
	It's not exactly related to PPC, but I changed 
	if (latency < preempt_max_latency) to use <= instead, as I was
	getting the same latency printed out over and over.
	
I haven't (yet) fixed any of the specific latencies I've found on the
Mac; this patch just supplies the generic functionality.

Signed-off-by: Scott Wood <scott.wood@timesys.com>

diff -urN vpP7/arch/ppc/Kconfig vpP7-ppc/arch/ppc/Kconfig
--- vpP7/arch/ppc/Kconfig	2004-08-17 15:22:33.000000000 -0400
+++ vpP7-ppc/arch/ppc/Kconfig	2004-08-23 13:57:14.000000000 -0400
@@ -808,6 +808,19 @@
 	  Say Y here if you are building a kernel for a desktop, embedded
 	  or real-time system.  Say N if you are unsure.
 
+config PREEMPT_VOLUNTARY
+	bool "Voluntary Kernel Preemption"
+	default y
+	help
+	  This option reduces the latency of the kernel by adding more
+	  "explicit preemption points" to the kernel code. These new
+	  preemption points have been selected to minimize the maximum
+	  latency of rescheduling, providing faster application reactions.
+
+	  Say Y here if you are building a kernel for a desktop system.
+	  Say N if you are unsure.
+
+
 config HIGHMEM
 	bool "High memory support"
 
diff -urN vpP7/arch/ppc/kernel/entry.S vpP7-ppc/arch/ppc/kernel/entry.S
--- vpP7/arch/ppc/kernel/entry.S	2004-08-17 15:22:33.000000000 -0400
+++ vpP7-ppc/arch/ppc/kernel/entry.S	2004-08-23 13:57:14.000000000 -0400
@@ -610,6 +610,11 @@
 
 /* N.B. the only way to get here is from the beq following ret_from_except. */
 resume_kernel:
+	lis	r9, kernel_preemption@ha
+	lwz	r9, kernel_preemption@l(r9)
+	cmpwi	r9, 0
+	bne	restore
+
 	/* check current_thread_info->preempt_count */
 	rlwinm	r9,r1,0,0,18
 	lwz	r0,TI_PREEMPT(r9)
diff -urN vpP7/arch/ppc/kernel/irq.c vpP7-ppc/arch/ppc/kernel/irq.c
--- vpP7/arch/ppc/kernel/irq.c	2004-08-17 15:22:33.000000000 -0400
+++ vpP7-ppc/arch/ppc/kernel/irq.c	2004-08-23 13:57:14.000000000 -0400
@@ -64,8 +64,6 @@
 void enable_irq(unsigned int irq_nr);
 void disable_irq(unsigned int irq_nr);
 
-static void register_irq_proc (unsigned int irq);
-
 #define MAXCOUNT 10000000
 
 irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned = {
@@ -100,6 +98,7 @@
 	unsigned int i;
 	if ( mem_init_done )
 		return kmalloc(size,pri);
+		
 	for ( i = 0; i < IRQ_KMALLOC_ENTRIES ; i++ )
 		if ( ! ( cache_bitmask & (1<<i) ) )
 		{
@@ -121,107 +120,6 @@
 	kfree(ptr);
 }
 
-int
-setup_irq(unsigned int irq, struct irqaction * new)
-{
-	int shared = 0;
-	unsigned long flags;
-	struct irqaction *old, **p;
-	irq_desc_t *desc = irq_desc + irq;
-
-	/*
-	 * Some drivers like serial.c use request_irq() heavily,
-	 * so we have to be careful not to interfere with a
-	 * running system.
-	 */
-	if (new->flags & SA_SAMPLE_RANDOM) {
-		/*
-		 * This function might sleep, we want to call it first,
-		 * outside of the atomic block.
-		 * Yes, this might clear the entropy pool if the wrong
-		 * driver is attempted to be loaded, without actually
-		 * installing a new handler, but is this really a problem,
-		 * only the sysadmin is able to do this.
-		 */
-		rand_initialize_irq(irq);
-	}
-
-	/*
-	 * The following block of code has to be executed atomically
-	 */
-	spin_lock_irqsave(&desc->lock,flags);
-	p = &desc->action;
-	if ((old = *p) != NULL) {
-		/* Can't share interrupts unless both agree to */
-		if (!(old->flags & new->flags & SA_SHIRQ)) {
-			spin_unlock_irqrestore(&desc->lock,flags);
-			return -EBUSY;
-		}
-
-		/* add new interrupt at end of irq queue */
-		do {
-			p = &old->next;
-			old = *p;
-		} while (old);
-		shared = 1;
-	}
-
-	*p = new;
-
-	if (!shared) {
-		desc->depth = 0;
-		desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING);
-		if (desc->handler) {
-			if (desc->handler->startup)
-				desc->handler->startup(irq);
-			else if (desc->handler->enable)
-				desc->handler->enable(irq);
-		}
-	}
-	spin_unlock_irqrestore(&desc->lock,flags);
-
-	register_irq_proc(irq);
-	return 0;
-}
-
-void free_irq(unsigned int irq, void* dev_id)
-{
-	irq_desc_t *desc;
-	struct irqaction **p;
-	unsigned long flags;
-
-	desc = irq_desc + irq;
-	spin_lock_irqsave(&desc->lock,flags);
-	p = &desc->action;
-	for (;;) {
-		struct irqaction * action = *p;
-		if (action) {
-			struct irqaction **pp = p;
-			p = &action->next;
-			if (action->dev_id != dev_id)
-				continue;
-
-			/* Found it - now remove it from the list of entries */
-			*pp = action->next;
-			if (!desc->action) {
-				desc->status |= IRQ_DISABLED;
-				mask_irq(irq);
-			}
-			spin_unlock_irqrestore(&desc->lock,flags);
-
-			synchronize_irq(irq);
-			irq_kfree(action);
-			return;
-		}
-		printk("Trying to free free IRQ%d\n",irq);
-		spin_unlock_irqrestore(&desc->lock,flags);
-		break;
-	}
-	return;
-}
-
-EXPORT_SYMBOL(free_irq);
-
 int request_irq(unsigned int irq,
 	irqreturn_t (*handler)(int, void *, struct pt_regs *),
 	unsigned long irqflags, const char * devname, void *dev_id)
@@ -262,95 +160,6 @@
 
 EXPORT_SYMBOL(request_irq);
 
-/*
- * Generic enable/disable code: this just calls
- * down into the PIC-specific version for the actual
- * hardware disable after having gotten the irq
- * controller lock.
- */
-
-/**
- *	disable_irq_nosync - disable an irq without waiting
- *	@irq: Interrupt to disable
- *
- *	Disable the selected interrupt line. Disables of an interrupt
- *	stack. Unlike disable_irq(), this function does not ensure existing
- *	instances of the IRQ handler have completed before returning.
- *
- *	This function may be called from IRQ context.
- */
-
-void disable_irq_nosync(unsigned int irq)
-{
-	irq_desc_t *desc = irq_desc + irq;
-	unsigned long flags;
-
-	spin_lock_irqsave(&desc->lock, flags);
-	if (!desc->depth++) {
-		if (!(desc->status & IRQ_PER_CPU))
-			desc->status |= IRQ_DISABLED;
-		mask_irq(irq);
-	}
-	spin_unlock_irqrestore(&desc->lock, flags);
-}
-
-/**
- *	disable_irq - disable an irq and wait for completion
- *	@irq: Interrupt to disable
- *
- *	Disable the selected interrupt line. Disables of an interrupt
- *	stack. That is for two disables you need two enables. This
- *	function waits for any pending IRQ handlers for this interrupt
- *	to complete before returning. If you use this function while
- *	holding a resource the IRQ handler may need you will deadlock.
- *
- *	This function may be called - with care - from IRQ context.
- */
-
-void disable_irq(unsigned int irq)
-{
-	irq_desc_t *desc = irq_desc + irq;
-	disable_irq_nosync(irq);
-	if (desc->action)
-		synchronize_irq(irq);
-}
-
-/**
- *	enable_irq - enable interrupt handling on an irq
- *	@irq: Interrupt to enable
- *
- *	Re-enables the processing of interrupts on this IRQ line
- *	providing no disable_irq calls are now in effect.
- *
- *	This function may be called from IRQ context.
- */
-
-void enable_irq(unsigned int irq)
-{
-	irq_desc_t *desc = irq_desc + irq;
-	unsigned long flags;
-
-	spin_lock_irqsave(&desc->lock, flags);
-	switch (desc->depth) {
-	case 1: {
-		unsigned int status = desc->status & ~IRQ_DISABLED;
-		desc->status = status;
-		if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
-			desc->status = status | IRQ_REPLAY;
-			hw_resend_irq(desc->handler,irq);
-		}
-		unmask_irq(irq);
-		/* fall-through */
-	}
-	default:
-		desc->depth--;
-		break;
-	case 0:
-		printk("enable_irq(%u) unbalanced\n", irq);
-	}
-	spin_unlock_irqrestore(&desc->lock, flags);
-}
-
 int show_interrupts(struct seq_file *p, void *v)
 {
 	int i = *(loff_t *) v, j;
@@ -410,24 +219,6 @@
 	return 0;
 }
 
-static inline void
-handle_irq_event(int irq, struct pt_regs *regs, struct irqaction *action)
-{
-	int status = 0;
-
-	if (!(action->flags & SA_INTERRUPT))
-		local_irq_enable();
-
-	do {
-		status |= action->flags;
-		action->handler(irq, action->dev_id, regs);
-		action = action->next;
-	} while (action);
-	if (status & SA_SAMPLE_RANDOM)
-		add_interrupt_randomness(irq);
-	local_irq_disable();
-}
-
 /*
  * Eventually, this should take an array of interrupts and an array size
  * so it can dispatch multiple interrupts.
@@ -482,6 +273,8 @@
 	if (unlikely(!action))
 		goto out;
 
+	if (generic_redirect_hardirq(desc))
+		goto out_no_end;
 
 	/*
 	 * Edge triggered interrupts need to remember
@@ -494,10 +287,14 @@
 	 * SMP environment.
 	 */
 	for (;;) {
+		irqreturn_t action_ret;
+	
 		spin_unlock(&desc->lock);
-		handle_irq_event(irq, regs, action);
+		action_ret = generic_handle_IRQ_event(irq, regs, action);
 		spin_lock(&desc->lock);
-
+		
+		if (!noirqdebug)
+			generic_note_interrupt(irq, desc, action_ret);
 		if (likely(!(desc->status & IRQ_PENDING)))
 			break;
 		desc->status &= ~IRQ_PENDING;
@@ -514,13 +311,15 @@
 		else if (irq_desc[irq].handler->enable)
 			irq_desc[irq].handler->enable(irq);
 	}
+
+out_no_end:
 	spin_unlock(&desc->lock);
 }
 
 void do_IRQ(struct pt_regs *regs)
 {
 	int irq, first = 1;
-        irq_enter();
+	irq_enter();
 
 	/*
 	 * Every platform is required to implement ppc_md.get_irq.
@@ -537,7 +336,7 @@
 	if (irq != -2 && first)
 		/* That's not SMP safe ... but who cares ? */
 		ppc_spurious_interrupts++;
-        irq_exit();
+	irq_exit();
 }
 
 unsigned long probe_irq_on (void)
@@ -559,148 +358,6 @@
 	return 0;
 }
 
-#ifdef CONFIG_SMP
-void synchronize_irq(unsigned int irq)
-{
-	while (irq_desc[irq].status & IRQ_INPROGRESS)
-		barrier();
-}
-#endif /* CONFIG_SMP */
-
-static struct proc_dir_entry *root_irq_dir;
-static struct proc_dir_entry *irq_dir[NR_IRQS];
-static struct proc_dir_entry *smp_affinity_entry[NR_IRQS];
-
-#ifdef CONFIG_IRQ_ALL_CPUS
-#define DEFAULT_CPU_AFFINITY CPU_MASK_ALL
-#else
-#define DEFAULT_CPU_AFFINITY cpumask_of_cpu(0)
-#endif
-
-cpumask_t irq_affinity [NR_IRQS];
-
-static int irq_affinity_read_proc (char *page, char **start, off_t off,
-			int count, int *eof, void *data)
-{
-	int len = cpumask_scnprintf(page, count, irq_affinity[(long)data]);
-	if (count - len < 2)
-		return -EINVAL;
-	len += sprintf(page + len, "\n");
-	return len;
-}
-
-static int irq_affinity_write_proc (struct file *file, const char __user *buffer,
-					unsigned long count, void *data)
-{
-	int irq = (int) data, full_count = count, err;
-	cpumask_t new_value, tmp;
-
-	if (!irq_desc[irq].handler->set_affinity)
-		return -EIO;
-
-	err = cpumask_parse(buffer, count, new_value);
-
-	/*
-	 * Do not allow disabling IRQs completely - it's a too easy
-	 * way to make the system unusable accidentally :-) At least
-	 * one online CPU still has to be targeted.
-	 *
-	 * We assume a 1-1 logical<->physical cpu mapping here.  If
-	 * we assume that the cpu indices in /proc/irq/../smp_affinity
-	 * are actually logical cpu #'s then we have no problem.
-	 *  -- Cort <cort@fsmlabs.com>
-	 */
-	cpus_and(tmp, new_value, cpu_online_map);
-	if (cpus_empty(tmp))
-		return -EINVAL;
-
-	irq_affinity[irq] = new_value;
-	irq_desc[irq].handler->set_affinity(irq, new_value);
-
-	return full_count;
-}
-
-static int prof_cpu_mask_read_proc (char *page, char **start, off_t off,
-			int count, int *eof, void *data)
-{
-	int len = cpumask_scnprintf(page, count, *(cpumask_t *)data);
-	if (count - len < 2)
-		return -EINVAL;
-	len += sprintf(page + len, "\n");
-	return len;
-}
-
-static int prof_cpu_mask_write_proc (struct file *file, const char __user *buffer,
-					unsigned long count, void *data)
-{
-	int err;
-	int full_count = count;
-	cpumask_t *mask = (cpumask_t *)data;
-	cpumask_t new_value;
-
-	err = cpumask_parse(buffer, count, new_value);
-	if (err)
-		return err;
-
-	*mask = new_value;
-	return full_count;
-}
-
-#define MAX_NAMELEN 10
-
-static void register_irq_proc (unsigned int irq)
-{
-	struct proc_dir_entry *entry;
-	char name [MAX_NAMELEN];
-
-	if (!root_irq_dir || (irq_desc[irq].handler == NULL) || irq_dir[irq])
-		return;
-
-	memset(name, 0, MAX_NAMELEN);
-	sprintf(name, "%d", irq);
-
-	/* create /proc/irq/1234 */
-	irq_dir[irq] = proc_mkdir(name, root_irq_dir);
-
-	/* create /proc/irq/1234/smp_affinity */
-	entry = create_proc_entry("smp_affinity", 0600, irq_dir[irq]);
-
-	entry->nlink = 1;
-	entry->data = (void *)irq;
-	entry->read_proc = irq_affinity_read_proc;
-	entry->write_proc = irq_affinity_write_proc;
-
-	smp_affinity_entry[irq] = entry;
-}
-
-unsigned long prof_cpu_mask = -1;
-
-void init_irq_proc (void)
-{
-	struct proc_dir_entry *entry;
-	int i;
-
-	/* create /proc/irq */
-	root_irq_dir = proc_mkdir("irq", NULL);
-
-	/* create /proc/irq/prof_cpu_mask */
-	entry = create_proc_entry("prof_cpu_mask", 0600, root_irq_dir);
-
-	entry->nlink = 1;
-	entry->data = (void *)&prof_cpu_mask;
-	entry->read_proc = prof_cpu_mask_read_proc;
-	entry->write_proc = prof_cpu_mask_write_proc;
-
-	/*
-	 * Create entries for all existing IRQs.
-	 */
-	for (i = 0; i < NR_IRQS; i++) {
-		if (irq_desc[i].handler == NULL)
-			continue;
-		register_irq_proc(i);
-	}
-}
-
 irqreturn_t no_action(int irq, void *dev, struct pt_regs *regs)
 {
 	return IRQ_NONE;
@@ -708,10 +365,7 @@
 
 void __init init_IRQ(void)
 {
-	int i;
-
-	for (i = 0; i < NR_IRQS; ++i)
-		irq_affinity[i] = DEFAULT_CPU_AFFINITY;
-
 	ppc_md.init_IRQ();
 }
+
+struct hw_interrupt_type no_irq_type;
diff -urN vpP7/arch/ppc/kernel/misc.S vpP7-ppc/arch/ppc/kernel/misc.S
--- vpP7/arch/ppc/kernel/misc.S	2004-08-17 15:22:33.000000000 -0400
+++ vpP7-ppc/arch/ppc/kernel/misc.S	2004-08-23 16:07:29.000000000 -0400
@@ -1165,6 +1165,60 @@
 _GLOBAL(__main)
 	blr
 
+#ifdef CONFIG_LATENCY_TRACE
+
+_GLOBAL(_mcount)
+	stwu	r1, -48(r1)
+
+	stw	r3, 8(r1)
+	stw	r4, 12(r1)
+	stw	r5, 16(r1)
+	stw	r6, 20(r1)
+	stw	r7, 24(r1)
+	stw	r8, 28(r1)
+	stw	r9, 32(r1)
+	stw	r10, 36(r1)
+
+	mflr	r3
+	stw	r3, 40(r1)
+
+	mfcr	r0
+	stw	r0, 44(r1)
+
+	lwz	r4, 52(r1)
+
+	// Don't call do_mcount if we haven't relocated to 0xc0000000 yet.
+	// This assumes that the ordinary load address is below
+	// 0x80000000.
+
+	andis.	r0, r3, 0x8000
+	beq-	mcount_out
+	bl	do_mcount
+mcount_out:
+
+	lwz	r3, 8(r1)
+	lwz	r4, 12(r1)
+	lwz	r5, 16(r1)
+	lwz	r6, 20(r1)
+	lwz	r7, 24(r1)
+	lwz	r8, 28(r1)
+	lwz	r9, 32(r1)
+	lwz	r10, 36(r1)
+
+	lwz	r0, 40(r1)
+	mtctr	r0
+
+	lwz	r0, 44(r1)
+	mtcr	r0
+
+	lwz	r0, 52(r1)
+	mtlr	r0
+
+	addi	r1, r1, 48
+	bctr
+
+#endif
+
 #define SYSCALL(name) \
 _GLOBAL(name) \
 	li	r0,__NR_##name; \
diff -urN vpP7/arch/ppc/kernel/ppc_ksyms.c vpP7-ppc/arch/ppc/kernel/ppc_ksyms.c
--- vpP7/arch/ppc/kernel/ppc_ksyms.c	2004-08-17 15:22:33.000000000 -0400
+++ vpP7-ppc/arch/ppc/kernel/ppc_ksyms.c	2004-08-23 13:57:14.000000000 -0400
@@ -84,9 +84,6 @@
 EXPORT_SYMBOL(sys_sigreturn);
 EXPORT_SYMBOL(ppc_n_lost_interrupts);
 EXPORT_SYMBOL(ppc_lost_interrupts);
-EXPORT_SYMBOL(enable_irq);
-EXPORT_SYMBOL(disable_irq);
-EXPORT_SYMBOL(disable_irq_nosync);
 EXPORT_SYMBOL(probe_irq_mask);
 
 EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
@@ -205,7 +202,6 @@
 #ifdef CONFIG_SMP
 EXPORT_SYMBOL(smp_call_function);
 EXPORT_SYMBOL(smp_hw_index);
-EXPORT_SYMBOL(synchronize_irq);
 #endif
 
 EXPORT_SYMBOL(ppc_md);
diff -urN vpP7/arch/ppc/platforms/pmac_pic.c vpP7-ppc/arch/ppc/platforms/pmac_pic.c
--- vpP7/arch/ppc/platforms/pmac_pic.c	2004-08-17 15:22:33.000000000 -0400
+++ vpP7-ppc/arch/ppc/platforms/pmac_pic.c	2004-08-23 13:57:14.000000000 -0400
@@ -440,8 +440,9 @@
 				OpenPIC_InitSenses = senses;
 				OpenPIC_NumInitSenses = 128;
 				openpic2_init(PMAC_OPENPIC2_OFFSET);
-				if (request_irq(irqctrler2->intrs[0].line, k2u3_action, 0,
-						"U3->K2 Cascade", NULL))
+				if (request_irq(irqctrler2->intrs[0].line, k2u3_action,
+				                SA_NODELAY | SA_INTERRUPT,
+				                "U3->K2 Cascade", NULL))
 					printk("Unable to get OpenPIC IRQ for cascade\n");
 			}
 #endif /* CONFIG_POWER4 */
@@ -455,7 +456,7 @@
 				if (pswitch && pswitch->n_intrs) {
 					nmi_irq = pswitch->intrs[0].line;
 					openpic_init_nmi_irq(nmi_irq);
-					request_irq(nmi_irq, xmon_irq, 0,
+					request_irq(nmi_irq, xmon_irq, SA_NODELAY,
 						    "NMI - XMON", NULL);
 				}
 			}
@@ -553,7 +554,7 @@
 			(int)irq_cascade);
 		for ( i = max_real_irqs ; i < max_irqs ; i++ )
 			irq_desc[i].handler = &gatwick_pic;
-		request_irq( irq_cascade, gatwick_action, SA_INTERRUPT,
+		request_irq( irq_cascade, gatwick_action, SA_INTERRUPT | SA_NODELAY,
 			     "cascade", NULL );
 	}
 	printk("System has %d possible interrupts\n", max_irqs);
@@ -562,7 +563,7 @@
 			max_real_irqs);
 
 #ifdef CONFIG_XMON
-	request_irq(20, xmon_irq, 0, "NMI - XMON", NULL);
+	request_irq(20, xmon_irq, SA_NODELAY, "NMI - XMON", NULL);
 #endif	/* CONFIG_XMON */
 }
 
diff -urN vpP7/arch/ppc/platforms/sbc82xx.c vpP7-ppc/arch/ppc/platforms/sbc82xx.c
--- vpP7/arch/ppc/platforms/sbc82xx.c	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc/platforms/sbc82xx.c	2004-08-23 13:57:14.000000000 -0400
@@ -212,7 +212,7 @@
 	sbc82xx_i8259_map[1] = sbc82xx_i8259_mask; /* Set interrupt mask */
 
 	/* Request cascade IRQ */
-	if (request_irq(SIU_INT_IRQ6, sbc82xx_i8259_demux, SA_INTERRUPT,
+	if (request_irq(SIU_INT_IRQ6, sbc82xx_i8259_demux, SA_INTERRUPT | SA_NODELAY,
 			"i8259 demux", 0)) {
 		printk("Installation of i8259 IRQ demultiplexer failed.\n");
 	}
diff -urN vpP7/arch/ppc/syslib/i8259.c vpP7-ppc/arch/ppc/syslib/i8259.c
--- vpP7/arch/ppc/syslib/i8259.c	2004-06-16 01:19:22.000000000 -0400
+++ vpP7-ppc/arch/ppc/syslib/i8259.c	2004-08-23 13:57:14.000000000 -0400
@@ -185,7 +185,7 @@
 	spin_unlock_irqrestore(&i8259_lock, flags);
 
 	/* reserve our resources */
-	request_irq( i8259_pic_irq_offset + 2, no_action, SA_INTERRUPT,
+	request_irq( i8259_pic_irq_offset + 2, no_action, SA_INTERRUPT | SA_NODELAY,
 				"82c59 secondary cascade", NULL );
 	request_resource(&ioport_resource, &pic1_iores);
 	request_resource(&ioport_resource, &pic2_iores);
diff -urN vpP7/arch/ppc/syslib/m8xx_setup.c vpP7-ppc/arch/ppc/syslib/m8xx_setup.c
--- vpP7/arch/ppc/syslib/m8xx_setup.c	2004-06-16 01:19:22.000000000 -0400
+++ vpP7-ppc/arch/ppc/syslib/m8xx_setup.c	2004-08-23 13:57:14.000000000 -0400
@@ -281,7 +281,8 @@
                 irq_desc[i].handler = &i8259_pic;
         i8259_pic.irq_offset = NR_SIU_INTS;
         i8259_init();
-        request_8xxirq(ISA_BRIDGE_INT, mbx_i8259_action, 0, "8259 cascade", NULL);
+        request_8xxirq(ISA_BRIDGE_INT, mbx_i8259_action,
+                       SA_INTERRUPT | SA_NODELAY, "8259 cascade", NULL);
         enable_irq(ISA_BRIDGE_INT);
 #endif
 }
diff -urN vpP7/arch/ppc/syslib/open_pic.c vpP7-ppc/arch/ppc/syslib/open_pic.c
--- vpP7/arch/ppc/syslib/open_pic.c	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc/syslib/open_pic.c	2004-08-23 13:57:14.000000000 -0400
@@ -580,16 +580,16 @@
 
 	/* IPIs are marked SA_INTERRUPT as they must run with irqs disabled */
 	request_irq(OPENPIC_VEC_IPI+open_pic_irq_offset,
-		    openpic_ipi_action, SA_INTERRUPT,
+		    openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		    "IPI0 (call function)", NULL);
 	request_irq(OPENPIC_VEC_IPI+open_pic_irq_offset+1,
-		    openpic_ipi_action, SA_INTERRUPT,
+		    openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		    "IPI1 (reschedule)", NULL);
 	request_irq(OPENPIC_VEC_IPI+open_pic_irq_offset+2,
-		    openpic_ipi_action, SA_INTERRUPT,
+		    openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		    "IPI2 (invalidate tlb)", NULL);
 	request_irq(OPENPIC_VEC_IPI+open_pic_irq_offset+3,
-		    openpic_ipi_action, SA_INTERRUPT,
+		    openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		    "IPI3 (xmon break)", NULL);
 
 	for ( i = 0; i < OPENPIC_NUM_IPI ; i++ )
@@ -687,7 +687,7 @@
 {
 	openpic_cascade_irq = irq;
 	openpic_cascade_fn = cascade_fn;
-	if (request_irq(irq, no_action, SA_INTERRUPT, name, NULL))
+	if (request_irq(irq, no_action, SA_INTERRUPT | SA_NODELAY, name, NULL))
 		printk("Unable to get OpenPIC IRQ %d for cascade\n",
 				irq - open_pic_irq_offset);
 }
@@ -798,6 +798,10 @@
 }
 #endif /* notused */
 
+#ifdef CONFIG_PREEMPT_VOLUNTARY
+#define __SLOW_VERSION__
+#endif
+
 /* No spinlocks, should not be necessary with the OpenPIC
  * (1 register = 1 interrupt and we have the desc lock).
  */
diff -urN vpP7/arch/ppc64/Kconfig vpP7-ppc/arch/ppc64/Kconfig
--- vpP7/arch/ppc64/Kconfig	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc64/Kconfig	2004-08-23 14:39:44.000000000 -0400
@@ -206,6 +206,18 @@
 	  Say Y here if you are building a kernel for a desktop, embedded
 	  or real-time system.  Say N if you are unsure.
 
+config PREEMPT_VOLUNTARY
+	bool "Voluntary Kernel Preemption"
+	default y
+	help
+	  This option reduces the latency of the kernel by adding more
+	  "explicit preemption points" to the kernel code. These new
+	  preemption points have been selected to minimize the maximum
+	  latency of rescheduling, providing faster application reactions.
+
+	  Say Y here if you are building a kernel for a desktop system.
+	  Say N if you are unsure.
+
 config MSCHUNKS
 	bool
 	depends on PPC_ISERIES
diff -urN vpP7/arch/ppc64/kernel/entry.S vpP7-ppc/arch/ppc64/kernel/entry.S
--- vpP7/arch/ppc64/kernel/entry.S	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/entry.S	2004-08-23 13:57:14.000000000 -0400
@@ -548,6 +548,12 @@
 #ifdef CONFIG_PREEMPT
 	andi.	r0,r3,MSR_PR	/* Returning to user mode? */
 	bne	user_work
+
+	LOADBASE(r8, kernel_preemption)
+	lwz	r8, kernel_preemption@l(r8)
+	cmpwi	r8, 0
+	bne	restore
+
 	/* Check that preempt_count() == 0 and interrupts are enabled */
 	lwz	r8,TI_PREEMPT(r9)
 	cmpwi	cr1,r8,0
diff -urN vpP7/arch/ppc64/kernel/i8259.c vpP7-ppc/arch/ppc64/kernel/i8259.c
--- vpP7/arch/ppc64/kernel/i8259.c	2004-06-16 01:20:26.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/i8259.c	2004-08-23 13:57:14.000000000 -0400
@@ -160,7 +160,7 @@
         outb(cached_A1, 0xA1);
         outb(cached_21, 0x21);
 	spin_unlock_irqrestore(&i8259_lock, flags);
-        request_irq( i8259_pic_irq_offset + 2, no_action, SA_INTERRUPT,
+        request_irq( i8259_pic_irq_offset + 2, no_action, SA_INTERRUPT | SA_NODELAY,
                      "82c59 secondary cascade", NULL );
         
 }
diff -urN vpP7/arch/ppc64/kernel/irq.c vpP7-ppc/arch/ppc64/kernel/irq.c
--- vpP7/arch/ppc64/kernel/irq.c	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/irq.c	2004-08-23 13:57:14.000000000 -0400
@@ -59,8 +59,6 @@
 extern void iSeries_smp_message_recv( struct pt_regs * );
 #endif
 
-static void register_irq_proc (unsigned int irq);
-
 irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned = {
 	[0 ... NR_IRQS-1] = {
 		.lock = SPIN_LOCK_UNLOCKED
@@ -71,78 +69,6 @@
 int ppc_spurious_interrupts;
 unsigned long lpevent_count;
 
-int
-setup_irq(unsigned int irq, struct irqaction * new)
-{
-	int shared = 0;
-	unsigned long flags;
-	struct irqaction *old, **p;
-	irq_desc_t *desc = get_irq_desc(irq);
-
-	/*
-	 * Some drivers like serial.c use request_irq() heavily,
-	 * so we have to be careful not to interfere with a
-	 * running system.
-	 */
-	if (new->flags & SA_SAMPLE_RANDOM) {
-		/*
-		 * This function might sleep, we want to call it first,
-		 * outside of the atomic block.
-		 * Yes, this might clear the entropy pool if the wrong
-		 * driver is attempted to be loaded, without actually
-		 * installing a new handler, but is this really a problem,
-		 * only the sysadmin is able to do this.
-		 */
-		rand_initialize_irq(irq);
-	}
-
-	/*
-	 * The following block of code has to be executed atomically
-	 */
-	spin_lock_irqsave(&desc->lock,flags);
-	p = &desc->action;
-	if ((old = *p) != NULL) {
-		/* Can't share interrupts unless both agree to */
-		if (!(old->flags & new->flags & SA_SHIRQ)) {
-			spin_unlock_irqrestore(&desc->lock,flags);
-			return -EBUSY;
-		}
-
-		/* add new interrupt at end of irq queue */
-		do {
-			p = &old->next;
-			old = *p;
-		} while (old);
-		shared = 1;
-	}
-
-	*p = new;
-
-	if (!shared) {
-		desc->depth = 0;
-		desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING | IRQ_INPROGRESS);
-		if (desc->handler && desc->handler->startup)
-			desc->handler->startup(irq);
-		unmask_irq(irq);
-	}
-	spin_unlock_irqrestore(&desc->lock,flags);
-
-	register_irq_proc(irq);
-	return 0;
-}
-
-#ifdef CONFIG_SMP
-
-inline void synchronize_irq(unsigned int irq)
-{
-	while (get_irq_desc(irq)->status & IRQ_INPROGRESS)
-		cpu_relax();
-}
-
-EXPORT_SYMBOL(synchronize_irq);
-
-#endif /* CONFIG_SMP */
-
 int request_irq(unsigned int irq,
 	irqreturn_t (*handler)(int, void *, struct pt_regs *),
 	unsigned long irqflags, const char * devname, void *dev_id)
@@ -152,8 +78,10 @@
 
 	if (irq >= NR_IRQS)
 		return -EINVAL;
-	if (!handler)
-		return -EINVAL;
+	if (!handler) {
+		free_irq(irq, dev_id);
+		return 0;
+	}
 
 	action = (struct irqaction *)
 		kmalloc(sizeof(struct irqaction), GFP_KERNEL);
@@ -178,140 +106,6 @@
 
 EXPORT_SYMBOL(request_irq);
 
-void free_irq(unsigned int irq, void *dev_id)
-{
-	irq_desc_t *desc = get_irq_desc(irq);
-	struct irqaction **p;
-	unsigned long flags;
-
-	spin_lock_irqsave(&desc->lock,flags);
-	p = &desc->action;
-	for (;;) {
-		struct irqaction * action = *p;
-		if (action) {
-			struct irqaction **pp = p;
-			p = &action->next;
-			if (action->dev_id != dev_id)
-				continue;
-
-			/* Found it - now remove it from the list of entries */
-			*pp = action->next;
-			if (!desc->action) {
-				desc->status |= IRQ_DISABLED;
-				mask_irq(irq);
-			}
-			spin_unlock_irqrestore(&desc->lock,flags);
-
-			/* Wait to make sure it's not being used on another CPU */
-			synchronize_irq(irq);
-			kfree(action);
-			return;
-		}
-		printk("Trying to free free IRQ%d\n",irq);
-		spin_unlock_irqrestore(&desc->lock,flags);
-		break;
-	}
-	return;
-}
-
-EXPORT_SYMBOL(free_irq);
-
-/*
- * Generic enable/disable code: this just calls
- * down into the PIC-specific version for the actual
- * hardware disable after having gotten the irq
- * controller lock. 
- */
- 
-/**
- *	disable_irq_nosync - disable an irq without waiting
- *	@irq: Interrupt to disable
- *
- *	Disable the selected interrupt line. Disables of an interrupt
- *	stack. Unlike disable_irq(), this function does not ensure existing
- *	instances of the IRQ handler have completed before returning.
- *
- *	This function may be called from IRQ context.
- */
- 
-inline void disable_irq_nosync(unsigned int irq)
-{
-	irq_desc_t *desc = get_irq_desc(irq);
-	unsigned long flags;
-
-	spin_lock_irqsave(&desc->lock, flags);
-	if (!desc->depth++) {
-		if (!(desc->status & IRQ_PER_CPU))
-			desc->status |= IRQ_DISABLED;
-		mask_irq(irq);
-	}
-	spin_unlock_irqrestore(&desc->lock, flags);
-}
-
-EXPORT_SYMBOL(disable_irq_nosync);
-
-/**
- *	disable_irq - disable an irq and wait for completion
- *	@irq: Interrupt to disable
- *
- *	Disable the selected interrupt line. Disables of an interrupt
- *	stack. That is for two disables you need two enables. This
- *	function waits for any pending IRQ handlers for this interrupt
- *	to complete before returning. If you use this function while
- *	holding a resource the IRQ handler may need you will deadlock.
- *
- *	This function may be called - with care - from IRQ context.
- */
- 
-void disable_irq(unsigned int irq)
-{
-	irq_desc_t *desc = get_irq_desc(irq);
-	disable_irq_nosync(irq);
-	if (desc->action)
-		synchronize_irq(irq);
-}
-
-EXPORT_SYMBOL(disable_irq);
-
-/**
- *	enable_irq - enable interrupt handling on an irq
- *	@irq: Interrupt to enable
- *
- *	Re-enables the processing of interrupts on this IRQ line
- *	providing no disable_irq calls are now in effect.
- *
- *	This function may be called from IRQ context.
- */
- 
-void enable_irq(unsigned int irq)
-{
-	irq_desc_t *desc = get_irq_desc(irq);
-	unsigned long flags;
-
-	spin_lock_irqsave(&desc->lock, flags);
-	switch (desc->depth) {
-	case 1: {
-		unsigned int status = desc->status & ~IRQ_DISABLED;
-		desc->status = status;
-		if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
-			desc->status = status | IRQ_REPLAY;
-			hw_resend_irq(desc->handler,irq);
-		}
-		unmask_irq(irq);
-		/* fall-through */
-	}
-	default:
-		desc->depth--;
-		break;
-	case 0:
-		printk("enable_irq(%u) unbalanced from %p\n", irq,
-		       __builtin_return_address(0));
-	}
-	spin_unlock_irqrestore(&desc->lock, flags);
-}
-
-EXPORT_SYMBOL(enable_irq);
-
 int show_interrupts(struct seq_file *p, void *v)
 {
 	int i = *(loff_t *) v, j;
@@ -359,106 +153,6 @@
 	return 0;
 }
 
-int handle_irq_event(int irq, struct pt_regs *regs, struct irqaction *action)
-{
-	int status = 0;
-	int retval = 0;
-
-	if (!(action->flags & SA_INTERRUPT))
-		local_irq_enable();
-
-	do {
-		status |= action->flags;
-		retval |= action->handler(irq, action->dev_id, regs);
-		action = action->next;
-	} while (action);
-	if (status & SA_SAMPLE_RANDOM)
-		add_interrupt_randomness(irq);
-	local_irq_disable();
-	return retval;
-}
-
-static void __report_bad_irq(int irq, irq_desc_t *desc, irqreturn_t action_ret)
-{
-	struct irqaction *action;
-
-	if (action_ret != IRQ_HANDLED && action_ret != IRQ_NONE) {
-		printk(KERN_ERR "irq event %d: bogus return value %x\n",
-				irq, action_ret);
-	} else {
-		printk(KERN_ERR "irq %d: nobody cared!\n", irq);
-	}
-	dump_stack();
-	printk(KERN_ERR "handlers:\n");
-	action = desc->action;
-	do {
-		printk(KERN_ERR "[<%p>]", action->handler);
-		print_symbol(" (%s)",
-			(unsigned long)action->handler);
-		printk("\n");
-		action = action->next;
-	} while (action);
-}
-
-static void report_bad_irq(int irq, irq_desc_t *desc, irqreturn_t action_ret)
-{
-	static int count = 100;
-
-	if (count) {
-		count--;
-		__report_bad_irq(irq, desc, action_ret);
-	}
-}
-
-static int noirqdebug;
-
-static int __init noirqdebug_setup(char *str)
-{
-	noirqdebug = 1;
-	printk("IRQ lockup detection disabled\n");
-	return 1;
-}
-
-__setup("noirqdebug", noirqdebug_setup);
-
-/*
- * If 99,900 of the previous 100,000 interrupts have not been handled then
- * assume that the IRQ is stuck in some manner.  Drop a diagnostic and try to
- * turn the IRQ off.
- *
- * (The other 100-of-100,000 interrupts may have been a correctly-functioning
- *  device sharing an IRQ with the failing one)
- *
- * Called under desc->lock
- */
-static void note_interrupt(int irq, irq_desc_t *desc, irqreturn_t action_ret)
-{
-	if (action_ret != IRQ_HANDLED) {
-		desc->irqs_unhandled++;
-		if (action_ret != IRQ_NONE)
-			report_bad_irq(irq, desc, action_ret);
-	}
-
-	desc->irq_count++;
-	if (desc->irq_count < 100000)
-		return;
-
-	desc->irq_count = 0;
-	if (desc->irqs_unhandled > 99900) {
-		/*
-		 * The interrupt is stuck
-		 */
-		__report_bad_irq(irq, desc, action_ret);
-		/*
-		 * Now kill the IRQ
-		 */
-		printk(KERN_EMERG "Disabling IRQ #%d\n", irq);
-		desc->status |= IRQ_DISABLED;
-		desc->handler->disable(irq);
-	}
-	desc->irqs_unhandled = 0;
-}
-
 /*
  * Eventually, this should take an array of interrupts and an array size
  * so it can dispatch multiple interrupts.
@@ -479,7 +173,7 @@
 	if (desc->status & IRQ_PER_CPU) {
 		/* no locking required for CPU-local interrupts: */
 		ack_irq(irq);
-		action_ret = handle_irq_event(irq, regs, desc->action);
+		action_ret = generic_handle_IRQ_event(irq, regs, desc->action);
 		desc->handler->end(irq);
 		return;
 	}
@@ -527,6 +221,9 @@
 	if (unlikely(!action))
 		goto out;
 
+	if (generic_redirect_hardirq(desc))
+		goto out_no_end;
+
 	/*
 	 * Edge triggered interrupts need to remember
 	 * pending events.
@@ -553,11 +250,11 @@
 				set_bits(irqtp->flags, &curtp->flags);
 		} else
 #endif
-			action_ret = handle_irq_event(irq, regs, action);
+			action_ret = generic_handle_IRQ_event(irq, regs, action);
 
 		spin_lock(&desc->lock);
 		if (!noirqdebug)
-			note_interrupt(irq, desc, action_ret);
+			generic_note_interrupt(irq, desc, action_ret);
 		if (likely(!(desc->status & IRQ_PENDING)))
 			break;
 		desc->status &= ~IRQ_PENDING;
@@ -574,6 +271,8 @@
 		else if (desc->handler->enable)
 			desc->handler->enable(irq);
 	}
+
+out_no_end:
 	spin_unlock(&desc->lock);
 }
 
@@ -687,174 +386,6 @@
 	irq_ctx_init();
 }
 
-static struct proc_dir_entry * root_irq_dir;
-static struct proc_dir_entry * irq_dir [NR_IRQS];
-static struct proc_dir_entry * smp_affinity_entry [NR_IRQS];
-
-/* Protected by get_irq_desc(irq)->lock. */
-#ifdef CONFIG_IRQ_ALL_CPUS
-cpumask_t irq_affinity [NR_IRQS] = { [0 ... NR_IRQS-1] = CPU_MASK_ALL };
-#else  /* CONFIG_IRQ_ALL_CPUS */
-cpumask_t irq_affinity [NR_IRQS] = { [0 ... NR_IRQS-1] = CPU_MASK_NONE };
-#endif /* CONFIG_IRQ_ALL_CPUS */
-
-static int irq_affinity_read_proc (char *page, char **start, off_t off,
-			int count, int *eof, void *data)
-{
-	int len = cpumask_scnprintf(page, count, irq_affinity[(long)data]);
-	if (count - len < 2)
-		return -EINVAL;
-	len += sprintf(page + len, "\n");
-	return len;
-}
-
-static int irq_affinity_write_proc (struct file *file, const char __user *buffer,
-					unsigned long count, void *data)
-{
-	unsigned int irq = (long)data;
-	irq_desc_t *desc = get_irq_desc(irq);
-	int ret;
-	cpumask_t new_value, tmp;
-
-	if (!desc->handler->set_affinity)
-		return -EIO;
-
-	ret = cpumask_parse(buffer, count, new_value);
-	if (ret != 0)
-		return ret;
-
-	/*
-	 * We check for CPU_MASK_ALL in xics to send irqs to all cpus.
-	 * In some cases CPU_MASK_ALL is smaller than the cpumask (eg
-	 * NR_CPUS == 32 and cpumask is a long), so we mask it here to
-	 * be consistent.
-	 */
-	cpus_and(new_value, new_value, CPU_MASK_ALL);
-
-	/*
-	 * Grab lock here so cpu_online_map can't change, and also
-	 * protect irq_affinity[].
-	 */
-	spin_lock(&desc->lock);
-
-	/*
-	 * Do not allow disabling IRQs completely - it's a too easy
-	 * way to make the system unusable accidentally :-) At least
-	 * one online CPU still has to be targeted.
-	 */
-	cpus_and(tmp, new_value, cpu_online_map);
-	if (cpus_empty(tmp)) {
-		ret = -EINVAL;
-		goto out;
-	}
-
-	irq_affinity[irq] = new_value;
-	desc->handler->set_affinity(irq, new_value);
-	ret = count;
-
-out:
-	spin_unlock(&desc->lock);
-	return ret;
-}
-
-static int prof_cpu_mask_read_proc (char *page, char **start, off_t off,
-			int count, int *eof, void *data)
-{
-	int len = cpumask_scnprintf(page, count, *(cpumask_t *)data);
-	if (count - len < 2)
-		return -EINVAL;
-	len += sprintf(page + len, "\n");
-	return len;
-}
-
-static int prof_cpu_mask_write_proc (struct file *file, const char __user *buffer,
-					unsigned long count, void *data)
-{
-	cpumask_t *mask = (cpumask_t *)data;
-	unsigned long full_count = count, err;
-	cpumask_t new_value;
-
-	err = cpumask_parse(buffer, count, new_value);
-	if (err)
-		return err;
-
-	*mask = new_value;
-
-#ifdef CONFIG_PPC_ISERIES
-	{
-		unsigned i;
-		for (i=0; i<NR_CPUS; ++i) {
-			if ( paca[i].prof_buffer && cpu_isset(i, new_value) )
-				paca[i].prof_enabled = 1;
-			else
-				paca[i].prof_enabled = 0;
-		}
-	}
-#endif
-
-	return full_count;
-}
-
-#define MAX_NAMELEN 10
-
-static void register_irq_proc (unsigned int irq)
-{
-	struct proc_dir_entry *entry;
-	char name [MAX_NAMELEN];
-
-	if (!root_irq_dir || (irq_desc[irq].handler == NULL) || irq_dir[irq])
-		return;
-
-	memset(name, 0, MAX_NAMELEN);
-	sprintf(name, "%d", irq);
-
-	/* create /proc/irq/1234 */
-	irq_dir[irq] = proc_mkdir(name, root_irq_dir);
-
-	/* create /proc/irq/1234/smp_affinity */
-	entry = create_proc_entry("smp_affinity", 0600, irq_dir[irq]);
-
-	if (entry) {
-		entry->nlink = 1;
-		entry->data = (void *)(long)irq;
-		entry->read_proc = irq_affinity_read_proc;
-		entry->write_proc = irq_affinity_write_proc;
-	}
-
-	smp_affinity_entry[irq] = entry;
-}
-
-unsigned long prof_cpu_mask = -1;
-
-void init_irq_proc (void)
-{
-	struct proc_dir_entry *entry;
-	int i;
-
-	/* create /proc/irq */
-	root_irq_dir = proc_mkdir("irq", NULL);
-
-	/* create /proc/irq/prof_cpu_mask */
-	entry = create_proc_entry("prof_cpu_mask", 0600, root_irq_dir);
-
-	if (!entry)
-		return;
-
-	entry->nlink = 1;
-	entry->data = (void *)&prof_cpu_mask;
-	entry->read_proc = prof_cpu_mask_read_proc;
-	entry->write_proc = prof_cpu_mask_write_proc;
-
-	/*
-	 * Create entries for all existing IRQs.
-	 */
-	for_each_irq(i) {
-		if (get_irq_desc(i)->handler == NULL)
-			continue;
-		register_irq_proc(i);
-	}
-}
-
 irqreturn_t no_action(int irq, void *dev, struct pt_regs *regs)
 {
 	return IRQ_NONE;
@@ -1014,3 +545,4 @@
 
 #endif /* CONFIG_IRQSTACKS */
 
+struct hw_interrupt_type no_irq_type;
diff -urN vpP7/arch/ppc64/kernel/misc.S vpP7-ppc/arch/ppc64/kernel/misc.S
--- vpP7/arch/ppc64/kernel/misc.S	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/misc.S	2004-08-23 17:27:11.000000000 -0400
@@ -120,7 +120,7 @@
 	std	r0,16(r1)
 	stdu	r1,THREAD_SIZE-112(r6)
 	mr	r1,r6
-	bl	.handle_irq_event
+	bl	.generic_handle_IRQ_event
 	ld	r1,0(r1)
 	ld	r0,16(r1)
 	mtlr	r0
@@ -600,6 +600,35 @@
 	ld	r30,-16(r1)
 	blr
 
+#ifdef CONFIG_LATENCY_TRACE
+
+_GLOBAL(_mcount)
+	ld	r5, 0(r1)
+	mflr	r3
+	stdu	r1, -112(r1)
+	ld	r4, 16(r5)
+	std	r3, 128(r1)
+
+	// Don't call do_mcount if we haven't relocated to
+	// 0xc000000000000000 yet.  This assumes that the ordinary
+	// load address is below 0x8000000000000000.
+
+	lis	r6, 0x8000
+	rldicr	r6, r6, 32, 31
+	and.	r0, r3, r6
+	
+	beq-	mcount_out
+	bl	.do_mcount
+mcount_out:
+
+	ld	r0, 128(r1)
+	mtlr	r0
+
+	addi	r1, r1, 112
+	blr
+
+#endif
+
 #ifdef CONFIG_PPC_ISERIES	/* hack hack hack */
 #define ppc_rtas	sys_ni_syscall
 #endif
diff -urN vpP7/arch/ppc64/kernel/open_pic.c vpP7-ppc/arch/ppc64/kernel/open_pic.c
--- vpP7/arch/ppc64/kernel/open_pic.c	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/open_pic.c	2004-08-23 16:44:16.000000000 -0400
@@ -78,6 +78,12 @@
 
 OpenPIC_SourcePtr ISU[OPENPIC_MAX_ISU];
 
+#ifdef CONFIG_PREEMPT_VOLUNTARY
+static void openpic_ack_irq(unsigned int irq);
+#else
+#define openpic_ack_irq NULL
+#endif
+
 static void openpic_end_irq(unsigned int irq_nr);
 static void openpic_set_affinity(unsigned int irq_nr, cpumask_t cpumask);
 
@@ -87,7 +93,7 @@
 	NULL,
 	openpic_enable_irq,
 	openpic_disable_irq,
-	NULL,
+	openpic_ack_irq,
 	openpic_end_irq,
 	openpic_set_affinity
 };
@@ -440,7 +446,7 @@
 
 	if (naca->interrupt_controller == IC_OPEN_PIC) {
 		/* Initialize the cascade */
-		if (request_irq(NUM_ISA_INTERRUPTS, no_action, SA_INTERRUPT,
+		if (request_irq(NUM_ISA_INTERRUPTS, no_action, SA_INTERRUPT | SA_NODELAY,
 				"82c59 cascade", NULL))
 			printk(KERN_ERR "Unable to get OpenPIC IRQ 0 for cascade\n");
 		i8259_init();
@@ -641,13 +647,13 @@
 		return;
 
 	/* IPIs are marked SA_INTERRUPT as they must run with irqs disabled */
-	request_irq(openpic_vec_ipi, openpic_ipi_action, SA_INTERRUPT,
+	request_irq(openpic_vec_ipi, openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		    "IPI0 (call function)", NULL);
-	request_irq(openpic_vec_ipi+1, openpic_ipi_action, SA_INTERRUPT,
+	request_irq(openpic_vec_ipi+1, openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		   "IPI1 (reschedule)", NULL);
-	request_irq(openpic_vec_ipi+2, openpic_ipi_action, SA_INTERRUPT,
+	request_irq(openpic_vec_ipi+2, openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		   "IPI2 (unused)", NULL);
-	request_irq(openpic_vec_ipi+3, openpic_ipi_action, SA_INTERRUPT,
+	request_irq(openpic_vec_ipi+3, openpic_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		   "IPI3 (debugger break)", NULL);
 
 	for ( i = 0; i < OPENPIC_NUM_IPI ; i++ )
@@ -834,11 +840,28 @@
 }
 #endif
 
+#ifdef CONFIG_PREEMPT_VOLUNTARY
+
+static void openpic_ack_irq(unsigned int irq_nr)
+{
+	openpic_disable_irq(irq_nr);
+	openpic_eoi();
+}
+
+static void openpic_end_irq(unsigned int irq_nr)
+{
+	openpic_enable_irq(irq_nr);
+}
+
+#else
+
 static void openpic_end_irq(unsigned int irq_nr)
 {
 	openpic_eoi();
 }
 
+#endif
+
 static void openpic_set_affinity(unsigned int irq_nr, cpumask_t cpumask)
 {
 	cpumask_t tmp;
diff -urN vpP7/arch/ppc64/kernel/open_pic_u3.c vpP7-ppc/arch/ppc64/kernel/open_pic_u3.c
--- vpP7/arch/ppc64/kernel/open_pic_u3.c	2004-06-16 01:18:37.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/open_pic_u3.c	2004-08-23 16:43:03.000000000 -0400
@@ -251,11 +251,30 @@
 				 (sense ? OPENPIC_SENSE_LEVEL : 0));
 }
 
+#ifdef CONFIG_PREEMPT_VOLUNTARY
+
+static void openpic2_ack_irq(unsigned int irq_nr)
+{
+	openpic2_disable_irq(irq_nr);
+	openpic2_eoi();
+}
+
+static void openpic2_end_irq(unsigned int irq_nr)
+{
+	openpic2_enable_irq(irq_nr);
+}
+
+#else
+
+#define openpic2_ack_irq NULL
+
 static void openpic2_end_irq(unsigned int irq_nr)
 {
 	openpic2_eoi();
 }
 
+#endif
+
 int openpic2_get_irq(struct pt_regs *regs)
 {
 	int irq = openpic2_irq();
@@ -271,7 +290,7 @@
 	NULL,
 	openpic2_enable_irq,
 	openpic2_disable_irq,
-	NULL,
+	openpic2_ack_irq,
 	openpic2_end_irq,
 };
 
diff -urN vpP7/arch/ppc64/kernel/pmac_setup.c vpP7-ppc/arch/ppc64/kernel/pmac_setup.c
--- vpP7/arch/ppc64/kernel/pmac_setup.c	2004-06-16 01:18:58.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/pmac_setup.c	2004-08-23 13:57:14.000000000 -0400
@@ -409,8 +409,8 @@
  */
 static int __init pmac_irq_cascade_init(void)
 {
-	if (request_irq(pmac_cascade_irq, pmac_u3_do_cascade, 0,
-			"U3->K2 Cascade", NULL))
+	if (request_irq(pmac_cascade_irq, pmac_u3_do_cascade,
+	                SA_NODELAY | SA_INTERRUPT, "U3->K2 Cascade", NULL))
 		printk(KERN_ERR "Unable to get OpenPIC IRQ for cascade\n");
 	return 0;
 }
diff -urN vpP7/arch/ppc64/kernel/xics.c vpP7-ppc/arch/ppc64/kernel/xics.c
--- vpP7/arch/ppc64/kernel/xics.c	2004-08-17 15:22:34.000000000 -0400
+++ vpP7-ppc/arch/ppc64/kernel/xics.c	2004-08-23 13:57:14.000000000 -0400
@@ -572,7 +572,7 @@
 	if (naca->interrupt_controller == IC_PPC_XIC &&
 	    xics_irq_8259_cascade != -1) {
 		if (request_irq(irq_offset_up(xics_irq_8259_cascade),
-				no_action, 0, "8259 cascade", NULL))
+				no_action, SA_NODELAY, "8259 cascade", NULL))
 			printk(KERN_ERR "xics_setup_i8259: couldn't get 8259 "
 					"cascade\n");
 		i8259_init();
@@ -587,7 +587,7 @@
 	virt_irq_to_real_map[XICS_IPI] = XICS_IPI;
 
 	/* IPIs are marked SA_INTERRUPT as they must run with irqs disabled */
-	request_irq(irq_offset_up(XICS_IPI), xics_ipi_action, SA_INTERRUPT,
+	request_irq(irq_offset_up(XICS_IPI), xics_ipi_action, SA_INTERRUPT | SA_NODELAY,
 		    "IPI", NULL);
 	get_irq_desc(irq_offset_up(XICS_IPI))->status |= IRQ_PER_CPU;
 }
diff -urN vpP7/include/asm-i386/hw_irq.h vpP7-ppc/include/asm-i386/hw_irq.h
--- vpP7/include/asm-i386/hw_irq.h	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/include/asm-i386/hw_irq.h	2004-08-23 13:57:14.000000000 -0400
@@ -54,7 +54,6 @@
 void init_8259A(int aeoi);
 void FASTCALL(send_IPI_self(int vector));
 void init_VISWS_APIC_irqs(void);
-extern void init_hardirqs(void);
 void setup_IO_APIC(void);
 void disable_IO_APIC(void);
 void print_IO_APIC(void);
diff -urN vpP7/include/asm-ppc/hardirq.h vpP7-ppc/include/asm-ppc/hardirq.h
--- vpP7/include/asm-ppc/hardirq.h	2004-06-16 01:18:37.000000000 -0400
+++ vpP7-ppc/include/asm-ppc/hardirq.h	2004-08-23 13:57:14.000000000 -0400
@@ -5,7 +5,7 @@
 #include <linux/config.h>
 #include <linux/cache.h>
 #include <linux/smp_lock.h>
-#include <asm/irq.h>
+#include <linux/irq.h>
 
 /* The __last_jiffy_stamp field is needed to ensure that no decrementer
  * interrupt is lost on SMP machines. Since on most CPUs it is in the same
@@ -71,15 +71,11 @@
  * Are we doing bottom half or hardware interrupt processing?
  * Are we in a softirq context? Interrupt context?
  */
-#define in_irq()		(hardirq_count())
-#define in_softirq()		(softirq_count())
+#define in_irq()		(hardirq_count() || (current->flags & PF_HARDIRQ))
+#define in_softirq()		(softirq_count() || (current->flags & PF_SOFTIRQ))
 #define in_interrupt()		(irq_count())
 
-
-#define hardirq_trylock()	(!in_interrupt())
-#define hardirq_endlock()	do { } while (0)
-
-#define irq_enter()		(preempt_count() += HARDIRQ_OFFSET)
+#define irq_enter()		(add_preempt_count(HARDIRQ_OFFSET))
 
 #ifdef CONFIG_PREEMPT
 # define in_atomic()	((preempt_count() & ~PREEMPT_ACTIVE) != kernel_locked())
@@ -94,17 +90,41 @@
 
 #define irq_exit()							\
 do {									\
-	preempt_count() -= IRQ_EXIT_OFFSET;				\
+	sub_preempt_count(IRQ_EXIT_OFFSET);				\
 	if (!in_interrupt() && softirq_pending(smp_processor_id()))	\
 		do_softirq();						\
 	preempt_enable_no_resched();					\
 } while (0)
 
-#ifndef CONFIG_SMP
-# define synchronize_irq(irq)	barrier()
-#else
-  extern void synchronize_irq(unsigned int irq);
-#endif /* CONFIG_SMP */
+static inline void synchronize_irq(unsigned int irq)
+{
+	generic_synchronize_irq(irq);
+}
+
+static inline void free_irq(unsigned int irq, void *dev_id)
+{
+	generic_free_irq(irq, dev_id);
+}
+
+static inline void disable_irq_nosync(unsigned int irq)
+{
+	generic_disable_irq_nosync(irq);
+}
+
+static inline void disable_irq(unsigned int irq)
+{
+	generic_disable_irq(irq);
+}
+
+static inline void enable_irq(unsigned int irq)
+{
+	generic_enable_irq(irq);
+}
+
+static inline int setup_irq(unsigned int irq, struct irqaction *action)
+{
+	return generic_setup_irq(irq, action);
+}
 
 #endif /* __ASM_HARDIRQ_H */
 #endif /* __KERNEL__ */
diff -urN vpP7/include/asm-ppc/irq.h vpP7-ppc/include/asm-ppc/irq.h
--- vpP7/include/asm-ppc/irq.h	2004-08-17 15:22:36.000000000 -0400
+++ vpP7-ppc/include/asm-ppc/irq.h	2004-08-23 13:57:14.000000000 -0400
@@ -6,10 +6,6 @@
 #include <asm/machdep.h>		/* ppc_md */
 #include <asm/atomic.h>
 
-extern void disable_irq(unsigned int);
-extern void disable_irq_nosync(unsigned int);
-extern void enable_irq(unsigned int);
-
 /*
  * These constants are used for passing information about interrupt
  * signal polarity and level/edge sensing to the low-level PIC chip
@@ -324,7 +320,6 @@
 
 struct irqaction;
 struct pt_regs;
-int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *);
 
 #endif /* _ASM_IRQ_H */
 #endif /* __KERNEL__ */
diff -urN vpP7/include/asm-ppc/signal.h vpP7-ppc/include/asm-ppc/signal.h
--- vpP7/include/asm-ppc/signal.h	2004-08-17 15:22:36.000000000 -0400
+++ vpP7-ppc/include/asm-ppc/signal.h	2004-08-23 13:57:14.000000000 -0400
@@ -111,6 +111,7 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+#define SA_NODELAY              0x02000000
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */
diff -urN vpP7/include/asm-ppc64/hardirq.h vpP7-ppc/include/asm-ppc64/hardirq.h
--- vpP7/include/asm-ppc64/hardirq.h	2004-08-17 15:22:36.000000000 -0400
+++ vpP7-ppc/include/asm-ppc64/hardirq.h	2004-08-23 13:57:14.000000000 -0400
@@ -12,6 +12,7 @@
 #include <linux/config.h>
 #include <linux/cache.h>
 #include <linux/preempt.h>
+#include <linux/irq.h>
 
 typedef struct {
 	unsigned int __softirq_pending;
@@ -70,15 +71,11 @@
  * Are we doing bottom half or hardware interrupt processing?
  * Are we in a softirq context? Interrupt context?
  */
-#define in_irq()		(hardirq_count())
-#define in_softirq()		(softirq_count())
+#define in_irq()		(hardirq_count() || (current->flags & PF_HARDIRQ))
+#define in_softirq()		(softirq_count() || (current->flags & PF_SOFTIRQ))
 #define in_interrupt()		(irq_count())
 
-
-#define hardirq_trylock()	(!in_interrupt())
-#define hardirq_endlock()	do { } while (0)
-
-#define irq_enter()		(preempt_count() += HARDIRQ_OFFSET)
+#define irq_enter()		(add_preempt_count(HARDIRQ_OFFSET))
 
 #ifdef CONFIG_PREEMPT
 # define in_atomic()	((preempt_count() & ~PREEMPT_ACTIVE) != kernel_locked())
@@ -89,20 +86,44 @@
 # define preemptible()	0
 # define IRQ_EXIT_OFFSET HARDIRQ_OFFSET
 #endif
+
 #define irq_exit()							\
 do {									\
-		preempt_count() -= IRQ_EXIT_OFFSET;			\
-		if (!in_interrupt() && softirq_pending(smp_processor_id())) \
-			do_softirq();					\
-		preempt_enable_no_resched();				\
+	sub_preempt_count(IRQ_EXIT_OFFSET);				\
+	if (!in_interrupt() && softirq_pending(smp_processor_id()))	\
+		do_softirq();						\
+	preempt_enable_no_resched();					\
 } while (0)
 
-#ifndef CONFIG_SMP
-# define synchronize_irq(irq)	barrier()
-#else
-  extern void synchronize_irq(unsigned int irq);
-#endif /* CONFIG_SMP */
+static inline void synchronize_irq(unsigned int irq)
+{
+	generic_synchronize_irq(irq);
+}
+
+static inline void free_irq(unsigned int irq, void *dev_id)
+{
+	generic_free_irq(irq, dev_id);
+}
+
+static inline void disable_irq_nosync(unsigned int irq)
+{
+	generic_disable_irq_nosync(irq);
+}
+
+static inline void disable_irq(unsigned int irq)
+{
+	generic_disable_irq(irq);
+}
+
+static inline void enable_irq(unsigned int irq)
+{
+	generic_enable_irq(irq);
+}
+
+static inline int setup_irq(unsigned int irq, struct irqaction *action)
+{
+	return generic_setup_irq(irq, action);
+}
 
-#endif /* __KERNEL__ */
-	
 #endif /* __ASM_HARDIRQ_H */
+#endif /* __KERNEL__ */
diff -urN vpP7/include/asm-ppc64/irq.h vpP7-ppc/include/asm-ppc64/irq.h
--- vpP7/include/asm-ppc64/irq.h	2004-08-17 15:22:36.000000000 -0400
+++ vpP7-ppc/include/asm-ppc64/irq.h	2004-08-23 15:42:48.000000000 -0400
@@ -17,10 +17,6 @@
  */
 #define NR_IRQS		512
 
-extern void disable_irq(unsigned int);
-extern void disable_irq_nosync(unsigned int);
-extern void enable_irq(unsigned int);
-
 /* this number is used when no interrupt has been assigned */
 #define NO_IRQ			(-1)
 
@@ -80,7 +76,6 @@
 
 struct irqaction;
 struct pt_regs;
-int handle_irq_event(int, struct pt_regs *, struct irqaction *);
 
 #ifdef CONFIG_IRQSTACKS
 /*
diff -urN vpP7/include/asm-ppc64/signal.h vpP7-ppc/include/asm-ppc64/signal.h
--- vpP7/include/asm-ppc64/signal.h	2004-08-17 15:22:36.000000000 -0400
+++ vpP7-ppc/include/asm-ppc64/signal.h	2004-08-23 13:57:14.000000000 -0400
@@ -108,6 +108,7 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+#define SA_NODELAY              0x02000000
 #endif
 
 #define SIG_BLOCK          0	/* for blocking signals */
diff -urN vpP7/include/linux/interrupt.h vpP7-ppc/include/linux/interrupt.h
--- vpP7/include/linux/interrupt.h	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/include/linux/interrupt.h	2004-08-23 13:57:14.000000000 -0400
@@ -95,7 +95,6 @@
 	void	*data;
 };
 
-extern void do_hardirq(irq_desc_t *desc);
 asmlinkage void do_softirq(void);
 extern void open_softirq(int nr, void (*action)(struct softirq_action*), void *data);
 extern void softirq_init(void);
diff -urN vpP7/include/linux/irq.h vpP7-ppc/include/linux/irq.h
--- vpP7/include/linux/irq.h	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/include/linux/irq.h	2004-08-23 13:57:14.000000000 -0400
@@ -83,6 +83,8 @@
 extern void generic_disable_irq(unsigned int irq);
 extern void generic_enable_irq(unsigned int irq);
 extern void generic_note_interrupt(int irq, irq_desc_t *desc, int action_ret);
+extern void do_hardirq(irq_desc_t *desc);
+extern void init_hardirqs(void);
 
 extern hw_irq_controller no_irq_type;  /* needed in every arch ? */
 
diff -urN vpP7/include/linux/kernel.h vpP7-ppc/include/linux/kernel.h
--- vpP7/include/linux/kernel.h	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/include/linux/kernel.h	2004-08-23 13:57:14.000000000 -0400
@@ -48,7 +48,10 @@
 #ifdef CONFIG_PREEMPT_VOLUNTARY
 extern int voluntary_resched(void);
 #else
-# define voluntary_resched() 0
+static inline int voluntary_resched(void)
+{
+	return 0;
+}
 #endif
 
 #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
diff -urN vpP7/include/linux/sched.h vpP7-ppc/include/linux/sched.h
--- vpP7/include/linux/sched.h	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/include/linux/sched.h	2004-08-23 13:57:14.000000000 -0400
@@ -1114,8 +1114,6 @@
  * submitted upstream will of course use need_resched()/cond_resched().
  */
 
-extern int voluntary_resched(void);
-
 static inline int voluntary_need_resched(void)
 {
 	if (voluntary_preemption >= 1)
@@ -1136,9 +1134,15 @@
 }
 
 #else
-# define voluntary_resched() 0
-# define voluntary_resched_lock(lock) 0
-# define voluntary_need_resched() 0
+static inline int voluntary_resched_lock(spinlock_t *lock)
+{
+	return 0;
+}
+
+static inline int voluntary_need_resched(void)
+{
+	return 0;
+}
 #endif
 
 /* Reevaluate whether the task has signals pending delivery.
diff -urN vpP7/init/main.c vpP7-ppc/init/main.c
--- vpP7/init/main.c	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/init/main.c	2004-08-23 13:57:14.000000000 -0400
@@ -397,9 +397,9 @@
 
 static void noinline rest_init(void)
 {
+	system_state = SYSTEM_BOOTING_SCHEDULER_OK;
 	kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
 	numa_default_policy();
-	system_state = SYSTEM_BOOTING_SCHEDULER_OK;
 	unlock_kernel();
  	cpu_idle();
 } 
@@ -669,6 +669,8 @@
 	smp_init();
 	sched_init_smp();
 
+	init_hardirqs();
+
 	/*
 	 * Do this before initcalls, because some drivers want to access
 	 * firmware files.
diff -urN vpP7/kernel/hardirq.c vpP7-ppc/kernel/hardirq.c
--- vpP7/kernel/hardirq.c	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/kernel/hardirq.c	2004-08-23 13:57:14.000000000 -0400
@@ -11,6 +11,7 @@
 #include <linux/mm.h>
 #include <linux/kallsyms.h>
 #include <linux/proc_fs.h>
+#include <linux/irq.h>
 #include <asm/uaccess.h>
 
 extern struct irq_desc irq_desc[NR_IRQS];
@@ -31,9 +32,8 @@
 	if (voluntary_preemption < 3 || (desc->status & IRQ_NODELAY))
 		return 0;
 
-	BUG_ON(!desc->thread);
 	BUG_ON(!irqs_disabled());
-	if (desc->thread->state != TASK_RUNNING)
+	if (desc->thread && desc->thread->state != TASK_RUNNING)
 		wake_up_process(desc->thread);
 
 	return 1;
@@ -369,7 +369,10 @@
 	if (!shared) {
 		desc->depth = 0;
 		desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING | IRQ_INPROGRESS);
-		desc->handler->startup(irq);
+		if (desc->handler->startup)
+			desc->handler->startup(irq);
+		else
+			desc->handler->enable(irq);
 	}
 	spin_unlock_irqrestore(&desc->lock,flags);
 
@@ -420,7 +423,10 @@
 			*pp = action->next;
 			if (!desc->action) {
 				desc->status |= IRQ_DISABLED;
-				desc->handler->shutdown(irq);
+				if (desc->handler->shutdown)
+					desc->handler->shutdown(irq);
+				else
+					desc->handler->disable(irq);
 			}
 			recalculate_desc_flags(desc);
 			spin_unlock_irqrestore(&desc->lock,flags);
@@ -480,9 +486,11 @@
 	return 0;
 }
 
+static int ok_to_create_irq_threads;
+
 static int start_irq_thread(int irq, struct irq_desc *desc)
 {
-	if (desc->thread)
+	if (desc->thread || !ok_to_create_irq_threads)
 		return 0;
 
 	printk("requesting new irq thread for IRQ%d...\n", irq);
@@ -492,9 +500,31 @@
 		return -ENOMEM;
 	}
 
+	// An interrupt may have come in before the thread pointer was
+	// stored in desc->thread; make sure the thread gets woken up in
+	// such a case.
+	
+	smp_mb();
+	
+	if (desc->status & IRQ_INPROGRESS)
+		wake_up_process(desc->thread);
+	
 	return 0;
 }
 
+void init_hardirqs(void)
+{	
+	int i;
+	ok_to_create_irq_threads = 1;
+
+	for (i = 0; i < NR_IRQS; i++) {
+		irq_desc_t *desc = irq_desc + i;
+		
+		if (desc->action && !(desc->status & IRQ_NODELAY))
+			start_irq_thread(i, desc);
+	}
+}
+
 #ifdef CONFIG_SMP
 
 static struct proc_dir_entry *smp_affinity_entry[NR_IRQS];
diff -urN vpP7/kernel/latency.c vpP7-ppc/kernel/latency.c
--- vpP7/kernel/latency.c	2004-08-23 13:41:28.000000000 -0400
+++ vpP7-ppc/kernel/latency.c	2004-08-23 14:06:38.000000000 -0400
@@ -16,6 +16,7 @@
 #include <linux/kallsyms.h>
 #include <linux/seq_file.h>
 #include <linux/interrupt.h>
+#include <asm/time.h>
 
 unsigned long preempt_thresh;
 unsigned long preempt_max_latency;
@@ -100,6 +101,8 @@
 	___trace(eip, parent_eip);
 }
 
+#ifdef CONFIG_X86
+
 void notrace mcount(void)
 {
 	MCOUNT_HEAD
@@ -112,6 +115,22 @@
 
 EXPORT_SYMBOL(mcount);
 
+#else
+
+#ifdef CONFIG_PPC
+void _mcount(void);
+EXPORT_SYMBOL(_mcount);
+#else
+#error What is mcount called?
+#endif
+
+void notrace do_mcount(void *func, void *called_from)
+{
+	___trace((unsigned long)func, (unsigned long)called_from);
+}
+
+#endif
+
 static void notrace print_name(struct seq_file *m, unsigned long eip)
 {
 	char namebuf[KSYM_NAME_LEN+1];
@@ -142,7 +161,13 @@
 
 static unsigned long notrace cycles_to_usecs(cycles_t delta)
 {
+#ifdef CONFIG_X86
 	do_div(delta, cpu_khz/1000);
+#elif defined(CONFIG_PPC)
+	delta = mulhwu(tb_to_us, delta);
+#else
+	#error Implement cycles_to_usecs.
+#endif
 
 	return (unsigned long) delta;
 }
@@ -248,18 +273,15 @@
 #endif
 	unsigned long parent_eip = (unsigned long)__builtin_return_address(1);
 	unsigned long latency;
-	cycles_t delta;
 
 	atomic_inc(&tr->disabled);
-	delta = get_cycles() - tr->preempt_timestamp;
-	do_div(delta, cpu_khz/1024);
-	latency = (unsigned long) delta;
+	latency = cycles_to_usecs(get_cycles() - tr->preempt_timestamp);
 
 	if (preempt_thresh) {
 		if (latency < preempt_thresh)
 			goto out;
 	} else {
-		if (latency < preempt_max_latency)
+		if (latency <= preempt_max_latency)
 			goto out;
 	}
 
--- vpP7/kernel/sysctl.c	2004-08-23 17:39:58.000000000 -0400
+++ vpP7-ppc/kernel/sysctl.c	2004-08-23 17:56:41.000000000 -0400
@@ -285,7 +285,7 @@
 		.data		= &preempt_max_latency,
 		.maxlen		= sizeof(unsigned long),
 		.mode		= 0644,
-		.proc_handler	= &proc_dointvec,
+		.proc_handler	= &proc_doulongvec_minmax,
 	},
 #ifdef CONFIG_LATENCY_TRACE
 	{

[patch] voluntary-preempt-2.6.8.1-P9

[Ingo Molnar]

* Scott Wood <scott@timesys.com> wrote:

> I have attached a port of the voluntary preempt patch to PPC and
> PPC64.  The patch is against P7, but it applies against P8 as well.

thanks Scott, i've applied your patch to my tree - all the changes and
improvements look good (except for a small compilation problem on x86,
asm/time.h doesnt exist there - asm/rtc.h does). The resulting code
booted fine on an SMP and on a UP x86 system. I've uploaded -P9:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9

(there are no other changes in -P9.)

	Ingo

Re: [patch] voluntary-preempt-2.6.8.1-P9

[K.R. Foley]

Ingo Molnar wrote:
> * Scott Wood <scott@timesys.com> wrote:
> 
> 
>>I have attached a port of the voluntary preempt patch to PPC and
>>PPC64.  The patch is against P7, but it applies against P8 as well.
> 
> 
> thanks Scott, i've applied your patch to my tree - all the changes and
> improvements look good (except for a small compilation problem on x86,
> asm/time.h doesnt exist there - asm/rtc.h does). The resulting code
> booted fine on an SMP and on a UP x86 system. I've uploaded -P9:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> 
> (there are no other changes in -P9.)
> 
> 	Ingo
> -

~254 usec latency seen in kswapd:

http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace2.txt

Re: [patch] voluntary-preempt-2.6.8.1-P9

[K.R. Foley]

Ingo Molnar wrote:
<snip>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> 
> (there are no other changes in -P9.)
> 
> 	Ingo

And a couple more interesting traces here:

http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace4.txt

and here:

http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace5.txt

kr

Re: [patch] PPC/PPC64 port of voluntary preempt patch

[Scott Wood]

On Mon, Aug 23, 2004 at 06:18:16PM -0400, Scott Wood wrote:
> I have attached a port of the voluntary preempt patch to PPC and
> PPC64.  The patch is against P7, but it applies against P8 as well.
> 
> I've tested it on a dual G5 Mac, both in uniprocessor and SMP.
> 
> Some notes on changes to the generic part of the patch/existing
> generic code:

Another thing that I forgot to mention is that I have some doubts as
to the current generic_synchronize_irq() implementation.  Given that
IRQs are now preemptible, a higher priority RT thread calling
synchronize_irq can't just spin waiting for the IRQ to complete, as
it never will (and it wouldn't be a great idea for non-RT tasks
either).  I see that a do_hardirq() call was added, presumably to
hurry completion of the interrupt, but is that really safe?  It looks
like that could end up re-entering handlers, and you'd still have a
partially executed handler after synchronize_irq() finishes (causing
not only an extra end() call, but possibly code being executed after
it's been unloaded, and other synchronization violations).

If I'm missing something, please let me know, but I don't see a good
way to implement it without blocking for the IRQ thread's completion
(such as with the per-IRQ waitqueues in M5).

-Scott

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Lee Revell]

On Tue, 2004-08-24 at 13:43, K.R. Foley wrote:
> Ingo Molnar wrote:
> > * Scott Wood <scott@timesys.com> wrote:
> > 
> > 
> >>I have attached a port of the voluntary preempt patch to PPC and
> >>PPC64.  The patch is against P7, but it applies against P8 as well.
> > 
> > 
> > thanks Scott, i've applied your patch to my tree - all the changes and
> > improvements look good (except for a small compilation problem on x86,
> > asm/time.h doesnt exist there - asm/rtc.h does). The resulting code
> > booted fine on an SMP and on a UP x86 system. I've uploaded -P9:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> > 
> > (there are no other changes in -P9.)
> > 
> > 	Ingo
> > -
> 
> ~254 usec latency seen in kswapd:
> 
> http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace2.txt
> 

I am able to generate unbounded latencies in kswapd by running `make
-j12' for any C++ program that uses KDE/Qt.  The build will allocate all
available RAM, then all available swap, then the machine grinds to a
halt.

I am not sure this is solvable though.  If you fire off a bunch of
processes that try to allocate way more memory than is physically
available then you will have worse problems than latency.

Lee

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Scott Wood]

On Tue, Aug 24, 2004 at 04:32:39PM -0400, Lee Revell wrote:
> I am not sure this is solvable though.  If you fire off a bunch of
> processes that try to allocate way more memory than is physically
> available then you will have worse problems than latency.

I don't see why it would be unsolvable if you limit the expectation
of reasonable latency to processes that have mlockall()ed and
allocated all the memory they need in advance (and don't have to wait
on processes that haven't).  Obviously, the latency for actually
allocating memory isn't going to be too good in such a case (though
strict no-overcommit could decrease the latency of failure to
allocate).

-Scott

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Lee Revell]

On Tue, 2004-08-24 at 02:14, Ingo Molnar wrote:
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> 

modprobe'ing causes this latency:

http://krustophenia.net/testresults.php?dataset=2.6.8.1-P9#/var/www/2.6.8.1-P9/trace1.txt

This one is caused by flood pinging the broadcast address (ping -s 65507
-f $BROADCAST_ADDRESS):

http://krustophenia.net/testresults.php?dataset=2.6.8.1-P9#/var/www/2.6.8.1-P9/trace2.txt

Lee

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Lee Revell]

On Tue, 2004-08-24 at 02:14, Ingo Molnar wrote:

>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> 

Here is an 815 usec latency triggered by mounting a 120GB ext3
partition:

http://krustophenia.net/testresults.php?dataset=2.6.8.1-P9#/var/www/2.6.8.1-P9/trace3.txt

Lee

Re: [patch] voluntary-preempt-2.6.8.1-P9

[K.R. Foley]

Ingo Molnar wrote:
> * Scott Wood <scott@timesys.com> wrote:
> 
> 
>>I have attached a port of the voluntary preempt patch to PPC and
>>PPC64.  The patch is against P7, but it applies against P8 as well.
> 
> 
> thanks Scott, i've applied your patch to my tree - all the changes and
> improvements look good (except for a small compilation problem on x86,
> asm/time.h doesnt exist there - asm/rtc.h does). The resulting code
> booted fine on an SMP and on a UP x86 system. I've uploaded -P9:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> 
> (there are no other changes in -P9.)
> 
> 	Ingo

latency trace of ~148 usec in scsi_request? I don't know if this is real 
or not. Note the 79 usec here:

00000001 0.107ms (+0.079ms): sd_init_command (scsi_prep_fn)

Entire trace is here:

http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace7.txt


Is this possible? This is not the first time I have seen this. There is 
another one here:

http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace5.txt

kr

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Lee Revell]

On Tue, 2004-08-24 at 23:17, K.R. Foley wrote:
> Ingo Molnar wrote:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> > 

> latency trace of ~148 usec in scsi_request? I don't know if this is real 
> or not. Note the 79 usec here:
> 
> 00000001 0.107ms (+0.079ms): sd_init_command (scsi_prep_fn)
> 
> Entire trace is here:
> 
> http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace7.txt
> 
> 
> Is this possible? This is not the first time I have seen this. There is 
> another one here:
> 
> http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace5.txt
> 

This looks like a real latency.  What is
/sys/block/sdX/queue/max_sectors_kb set to?  Does lowering it help?

Lee

Re: [patch] voluntary-preempt-2.6.8.1-P9

[K.R. Foley]

Any idea what is going on here?

dmesg gives me this:


(kswapd0/32): new 305 us maximum-latency critical section.
  => started at: <get_swap_page+0x28/0x280>
  => ended at:   <get_swap_page+0x96/0x280>
  [<c0135dbf>] check_preempt_timing+0x19f/0x240
  [<c0151bf6>] get_swap_page+0x96/0x280
  [<c0151bf6>] get_swap_page+0x96/0x280
  [<c0135f88>] sub_preempt_count+0x48/0x60
  [<c0135f88>] sub_preempt_count+0x48/0x60
  [<c0151bf6>] get_swap_page+0x96/0x280
  [<c015155a>] add_to_swap+0x2a/0xd0
  [<c0142a73>] shrink_list+0x4e3/0x530
  [<c01413a6>] lru_add_drain+0x36/0x70
  [<c0135f88>] sub_preempt_count+0x48/0x60
  [<c0142bc2>] shrink_cache+0x102/0x370
  [<c0135f88>] sub_preempt_count+0x48/0x60
  [<c0142c26>] shrink_cache+0x166/0x370
  [<c014345e>] shrink_zone+0xae/0xe0
  [<c0143871>] balance_pgdat+0x1e1/0x250
  [<c01439a5>] kswapd+0xc5/0xe0
  [<c0117cc0>] autoremove_wake_function+0x0/0x60
  [<c0106336>] ret_from_fork+0x6/0x14
  [<c0117cc0>] autoremove_wake_function+0x0/0x60
  [<c01438e0>] kswapd+0x0/0xe0
  [<c0104505>] kernel_thread_helper+0x5/0x10


The trace actually looks like this:

preemption latency trace v1.0.2
-------------------------------
  latency: 305 us, entries: 2 (2)
     -----------------
     | task: kswapd0/32, uid:0 nice:0 policy:0 rt_prio:0
     -----------------
  => started at: get_swap_page+0x28/0x280
  => ended at:   get_swap_page+0x96/0x280
=======>
00000001 0.000ms (+0.000ms): get_swap_page (add_to_swap)
00000001 0.306ms (+0.306ms): sub_preempt_count (get_swap_page)

Re: [patch] voluntary-preempt-2.6.8.1-P9 : oprofile latency at 3.3ms

[P.O. Gaillard]

Hello,

I have not seen anybody report this trace, so I hope it is not redundant.
I got this when starting oprofile, but if I stop oprofile and start it again, I 
do not get another trace.
	
	sincerely,

	P.O. Gaillard


Aug 24 13:17:31 centaurus kernel: (mount/2642): new 3381 us maximum-latency 
critical section.
Aug 24 13:17:31 centaurus kernel:  => started at: <voluntary_resched+0x35/0x70>
Aug 24 13:17:31 centaurus kernel:  => ended at:   <voluntary_resched+0x35/0x70>
Aug 24 13:17:31 centaurus kernel:  [<c015a0e4>] check_preempt_timing+0x1a4/0x240
Aug 24 13:17:31 centaurus kernel:  [<c03aca95>] voluntary_resched+0x35/0x70
Aug 24 13:17:31 centaurus kernel:  [<c03aca95>] voluntary_resched+0x35/0x70
Aug 24 13:17:31 centaurus kernel:  [<c015a1b6>] touch_preempt_timing+0x36/0x40
Aug 24 13:17:31 centaurus kernel:  [<c015a1b6>] touch_preempt_timing+0x36/0x40
Aug 24 13:17:31 centaurus kernel:  [<c03aca95>] voluntary_resched+0x35/0x70
Aug 24 13:17:31 centaurus kernel:  [<c01d5e4c>] vfs_quota_sync+0x3c/0x610
Aug 24 13:17:31 centaurus kernel:  [<c01dc5aa>] sync_dquots+0x3a/0x70
Aug 24 13:17:31 centaurus kernel:  [<c018da42>] fsync_super+0x32/0xd0
Aug 24 13:17:31 centaurus kernel:  [<c01967b3>] do_remount_sb+0x33/0x140
Aug 24 13:17:31 centaurus kernel:  [<c019771c>] get_sb_single+0x8c/0xc0
Aug 24 13:17:31 centaurus kernel:  [<c01977fa>] do_kern_mount+0xaa/0x180
Aug 24 13:17:31 centaurus kernel:  [<f8a62e70>] oprofilefs_fill_super+0x0/0xa0 
[oprofile]
Aug 24 13:17:31 centaurus kernel:  [<c01be70a>] do_new_mount+0x7a/0xc0
Aug 24 13:17:31 centaurus kernel:  [<c01bf5a9>] do_mount+0x169/0x1b0
Aug 24 13:17:31 centaurus kernel:  [<c01bf394>] copy_mount_options+0x14/0xc0
Aug 24 13:17:31 centaurus kernel:  [<c01bfbce>] sys_mount+0x12e/0x2b0
Aug 24 13:17:31 centaurus kernel:  [<c0107bfd>] sysenter_past_esp+0x52/0x71
Aug 24 13:17:54 centaurus sshd(pam_unix)[2726]: session opened for user tmr by 
(uid=500)

preemption latency trace v1.0.2
-------------------------------
  latency: 400 us, entries: 139 (139)
     -----------------
     | task: mount/2642, uid:0 nice:0 policy:0 rt_prio:0
     -----------------
  => started at: voluntary_resched+0x35/0x70
  => ended at:   voluntary_resched+0x35/0x70
=======>
00000001 0.000ms (+0.000ms): touch_preempt_timing (voluntary_resched)
00000001 0.000ms (+0.000ms): d_rehash (__oprofilefs_create_file)
00000001 0.000ms (+0.000ms): do_remount_sb (get_sb_single)
00000001 0.000ms (+0.000ms): bdev_read_only (do_remount_sb)
00000001 0.001ms (+0.000ms): shrink_dcache_sb (do_remount_sb)
00010002 0.276ms (+0.274ms): do_IRQ (shrink_dcache_sb)
00010003 0.276ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010003 0.276ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010002 0.277ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010002 0.277ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010003 0.278ms (+0.000ms): mark_offset_pmtmr (timer_interrupt)
00010003 0.282ms (+0.004ms): do_timer (timer_interrupt)
00010003 0.282ms (+0.000ms): update_process_times (do_timer)
00010003 0.283ms (+0.000ms): update_one_process (update_process_times)
00010003 0.283ms (+0.000ms): run_local_timers (update_process_times)
00010003 0.283ms (+0.000ms): raise_softirq (update_process_times)
00010003 0.283ms (+0.000ms): scheduler_tick (update_process_times)
00010003 0.284ms (+0.000ms): sched_clock (scheduler_tick)
00010003 0.285ms (+0.001ms): update_wall_time (do_timer)
00010003 0.285ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010003 0.286ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010003 0.286ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00000003 0.287ms (+0.000ms): do_softirq (do_IRQ)
00000003 0.287ms (+0.000ms): __do_softirq (do_softirq)
00000003 0.287ms (+0.000ms): wake_up_process (do_softirq)
00000003 0.287ms (+0.000ms): try_to_wake_up (wake_up_process)
00000003 0.287ms (+0.000ms): task_rq_lock (try_to_wake_up)
00000004 0.288ms (+0.000ms): activate_task (try_to_wake_up)
00000004 0.288ms (+0.000ms): sched_clock (activate_task)
00000004 0.288ms (+0.000ms): recalc_task_prio (activate_task)
00000004 0.288ms (+0.000ms): effective_prio (recalc_task_prio)
00000004 0.288ms (+0.000ms): enqueue_task (activate_task)
00000003 0.289ms (+0.000ms): preempt_schedule (try_to_wake_up)
00000002 0.660ms (+0.370ms): smp_apic_timer_interrupt (shrink_dcache_sb)
00010002 0.660ms (+0.000ms): profile_hook (smp_apic_timer_interrupt)
00010003 0.660ms (+0.000ms): notifier_call_chain (profile_hook)
00010002 0.661ms (+0.000ms): preempt_schedule (smp_apic_timer_interrupt)
00000003 0.661ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000003 0.661ms (+0.000ms): __do_softirq (do_softirq)
00010002 1.275ms (+0.613ms): do_IRQ (shrink_dcache_sb)
00010003 1.275ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010003 1.275ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010002 1.276ms (+0.000ms): preempt_schedule (do_IRQ)
00010002 1.276ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010002 1.276ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010003 1.276ms (+0.000ms): mark_offset_pmtmr (timer_interrupt)
00010003 1.279ms (+0.002ms): preempt_schedule (mark_offset_pmtmr)
00010003 1.281ms (+0.001ms): preempt_schedule (timer_interrupt)
00010003 1.281ms (+0.000ms): do_timer (timer_interrupt)
00010003 1.281ms (+0.000ms): update_process_times (do_timer)
00010003 1.281ms (+0.000ms): update_one_process (update_process_times)
00010003 1.281ms (+0.000ms): run_local_timers (update_process_times)
00010003 1.282ms (+0.000ms): raise_softirq (update_process_times)
00010003 1.282ms (+0.000ms): scheduler_tick (update_process_times)
00010003 1.282ms (+0.000ms): sched_clock (scheduler_tick)
00010003 1.283ms (+0.000ms): preempt_schedule (scheduler_tick)
00010003 1.283ms (+0.000ms): update_wall_time (do_timer)
00010003 1.283ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010002 1.283ms (+0.000ms): preempt_schedule (timer_interrupt)
00010003 1.284ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010003 1.284ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00010002 1.284ms (+0.000ms): preempt_schedule (do_IRQ)
00000003 1.284ms (+0.000ms): do_softirq (do_IRQ)
00000003 1.284ms (+0.000ms): __do_softirq (do_softirq)
00000002 1.659ms (+0.375ms): smp_apic_timer_interrupt (shrink_dcache_sb)
00010002 1.659ms (+0.000ms): profile_hook (smp_apic_timer_interrupt)
00010003 1.659ms (+0.000ms): notifier_call_chain (profile_hook)
00010002 1.660ms (+0.000ms): preempt_schedule (smp_apic_timer_interrupt)
00000003 1.660ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000003 1.660ms (+0.000ms): __do_softirq (do_softirq)
00010002 2.275ms (+0.614ms): do_IRQ (shrink_dcache_sb)
00010003 2.275ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010003 2.275ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010002 2.275ms (+0.000ms): preempt_schedule (do_IRQ)
00010002 2.275ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010002 2.275ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010003 2.276ms (+0.000ms): mark_offset_pmtmr (timer_interrupt)
00010003 2.278ms (+0.002ms): preempt_schedule (mark_offset_pmtmr)
00010003 2.280ms (+0.001ms): preempt_schedule (timer_interrupt)
00010003 2.280ms (+0.000ms): do_timer (timer_interrupt)
00010003 2.280ms (+0.000ms): update_process_times (do_timer)
00010003 2.280ms (+0.000ms): update_one_process (update_process_times)
00010003 2.281ms (+0.000ms): run_local_timers (update_process_times)
00010003 2.281ms (+0.000ms): raise_softirq (update_process_times)
00010003 2.281ms (+0.000ms): scheduler_tick (update_process_times)
00010003 2.281ms (+0.000ms): sched_clock (scheduler_tick)
00010003 2.282ms (+0.000ms): preempt_schedule (scheduler_tick)
00010003 2.282ms (+0.000ms): update_wall_time (do_timer)
00010003 2.282ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010002 2.282ms (+0.000ms): preempt_schedule (timer_interrupt)
00010003 2.282ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010003 2.283ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00010002 2.283ms (+0.000ms): preempt_schedule (do_IRQ)
00000003 2.283ms (+0.000ms): do_softirq (do_IRQ)
00000003 2.283ms (+0.000ms): __do_softirq (do_softirq)
00000002 2.659ms (+0.376ms): smp_apic_timer_interrupt (shrink_dcache_sb)
00010002 2.659ms (+0.000ms): profile_hook (smp_apic_timer_interrupt)
00010003 2.659ms (+0.000ms): notifier_call_chain (profile_hook)
00010002 2.660ms (+0.000ms): preempt_schedule (smp_apic_timer_interrupt)
00000003 2.660ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000003 2.660ms (+0.000ms): __do_softirq (do_softirq)
00010002 3.275ms (+0.615ms): do_IRQ (shrink_dcache_sb)
00010003 3.275ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010003 3.275ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010002 3.276ms (+0.000ms): preempt_schedule (do_IRQ)
00010002 3.276ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010002 3.276ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010003 3.276ms (+0.000ms): mark_offset_pmtmr (timer_interrupt)
00010003 3.279ms (+0.002ms): preempt_schedule (mark_offset_pmtmr)
00010003 3.281ms (+0.001ms): preempt_schedule (timer_interrupt)
00010003 3.281ms (+0.000ms): do_timer (timer_interrupt)
00010003 3.281ms (+0.000ms): update_process_times (do_timer)
00010003 3.281ms (+0.000ms): update_one_process (update_process_times)
00010003 3.281ms (+0.000ms): run_local_timers (update_process_times)
00010003 3.281ms (+0.000ms): raise_softirq (update_process_times)
00010003 3.281ms (+0.000ms): scheduler_tick (update_process_times)
00010003 3.281ms (+0.000ms): sched_clock (scheduler_tick)
00010003 3.282ms (+0.000ms): preempt_schedule (scheduler_tick)
00010003 3.282ms (+0.000ms): update_wall_time (do_timer)
00010003 3.282ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010002 3.282ms (+0.000ms): preempt_schedule (timer_interrupt)
00010003 3.282ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010003 3.283ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00010002 3.283ms (+0.000ms): preempt_schedule (do_IRQ)
00000003 3.283ms (+0.000ms): do_softirq (do_IRQ)
00000003 3.283ms (+0.000ms): __do_softirq (do_softirq)
00000001 3.378ms (+0.095ms): preempt_schedule (do_remount_sb)
00000001 3.379ms (+0.000ms): fsync_super (do_remount_sb)
00000001 3.379ms (+0.000ms): sync_inodes_sb (fsync_super)
00000001 3.379ms (+0.000ms): __read_page_state (sync_inodes_sb)
00000001 3.379ms (+0.000ms): __read_page_state (sync_inodes_sb)
00000002 3.380ms (+0.000ms): sync_sb_inodes (sync_inodes_sb)
00000001 3.380ms (+0.000ms): preempt_schedule (sync_inodes_sb)
00000001 3.380ms (+0.000ms): sync_dquots (fsync_super)
00000001 3.381ms (+0.000ms): vfs_quota_sync (sync_dquots)
00000001 3.381ms (+0.000ms): __might_sleep (vfs_quota_sync)
00000001 3.381ms (+0.000ms): voluntary_resched (vfs_quota_sync)
00000001 3.381ms (+0.000ms): __might_sleep (voluntary_resched)
00000001 3.382ms (+0.000ms): touch_preempt_timing (voluntary_resched)

Re: [patch] voluntary-preempt-2.6.8.1-P9

[K.R. Foley]

Lee Revell wrote:
> On Tue, 2004-08-24 at 23:17, K.R. Foley wrote:
> 
>>Ingo Molnar wrote:
>>
>>>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
>>>
> 
> 
>>latency trace of ~148 usec in scsi_request? I don't know if this is real 
>>or not. Note the 79 usec here:
>>
>>00000001 0.107ms (+0.079ms): sd_init_command (scsi_prep_fn)
>>
>>Entire trace is here:
>>
>>http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace7.txt
>>
>>
>>Is this possible? This is not the first time I have seen this. There is 
>>another one here:
>>
>>http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace5.txt
>>
> 
> 
> This looks like a real latency.  What is
> /sys/block/sdX/queue/max_sectors_kb set to?  Does lowering it help?
> 
> Lee
> 
> 
/sys/block/sda/queue/max_sectors_kb was set to 512, trying it at 256. 
Hard to say whether it is helping or not. Looking at dmesg I do see some 
traces for scsi_request in the range of 39 - 72 usec. However, anything 
higher (up to 115 usec) could be masked by one of the netif_skb 
latencies that I am still seeing. Not only that, but I have only caught 
a hand-full of these scsi traces in all of my testing.

kr

Re: [patch] voluntary-preempt-2.6.8.1-P9

[K.R. Foley]

Lee Revell wrote:
> On Tue, 2004-08-24 at 23:17, K.R. Foley wrote:
> 
>>Ingo Molnar wrote:
>>
>>>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
>>>
> 
> 
>>latency trace of ~148 usec in scsi_request? I don't know if this is real 
>>or not. Note the 79 usec here:
>>
>>00000001 0.107ms (+0.079ms): sd_init_command (scsi_prep_fn)
>>
>>Entire trace is here:
>>
>>http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace7.txt
>>
>>
>>Is this possible? This is not the first time I have seen this. There is 
>>another one here:
>>
>>http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace5.txt
>>
> 
> 
> This looks like a real latency.  What is
> /sys/block/sdX/queue/max_sectors_kb set to?  Does lowering it help?
> 
> Lee
> 
> 
Well I had no sooner sent the last message and another one of these 
popped up. This one is 123 usec:

http://www.cybsft.com/testresults/2.6.8.1-P9/latency_trace12.txt

kr

Re: [patch] PPC/PPC64 port of voluntary preempt patch

[Lee Revell]

On Tue, 2004-08-24 at 15:51, Scott Wood wrote:
> On Mon, Aug 23, 2004 at 06:18:16PM -0400, Scott Wood wrote:
> > I have attached a port of the voluntary preempt patch to PPC and
> > PPC64.  The patch is against P7, but it applies against P8 as well.
> > 
> > I've tested it on a dual G5 Mac, both in uniprocessor and SMP.
> > 
> > Some notes on changes to the generic part of the patch/existing
> > generic code:
> 
> Another thing that I forgot to mention is that I have some doubts as
> to the current generic_synchronize_irq() implementation.  Given that
> IRQs are now preemptible, a higher priority RT thread calling
> synchronize_irq can't just spin waiting for the IRQ to complete, as
> it never will (and it wouldn't be a great idea for non-RT tasks
> either).  I see that a do_hardirq() call was added, presumably to
> hurry completion of the interrupt, but is that really safe?  It looks
> like that could end up re-entering handlers, and you'd still have a
> partially executed handler after synchronize_irq() finishes (causing
> not only an extra end() call, but possibly code being executed after
> it's been unloaded, and other synchronization violations).
> 
> If I'm missing something, please let me know, but I don't see a good
> way to implement it without blocking for the IRQ thread's completion
> (such as with the per-IRQ waitqueues in M5).

I think Scott may be on to something.  There are several reports that P9
does not work on SMP machines at all - it either doesn't boot, locks up
the first time there is heavy IRQ activity (starting KDE), or locks up
as soon as the first RT process is run.  This is exactly the behavior
that would be expected if Scott is correct.  See this thread:

http://ccrma-mail.stanford.edu/pipermail/planetccrma/2004-August/005899.html

Does anyone have P9 working on SMP?  Fernando, can you see if M5 works
on SMP?  If this works it would seem that the preemptible IRQs are the
problem.

Lee

Re: [patch] PPC/PPC64 port of voluntary preempt patch

[Scott Wood]

On Wed, Aug 25, 2004 at 11:17:32PM -0400, Lee Revell wrote:
> I think Scott may be on to something.  There are several reports that P9
> does not work on SMP machines at all - it either doesn't boot, locks up
> the first time there is heavy IRQ activity (starting KDE), or locks up
> as soon as the first RT process is run.  This is exactly the behavior
> that would be expected if Scott is correct.  See this thread:
> 
> http://ccrma-mail.stanford.edu/pipermail/planetccrma/2004-August/005899.html
> 
> Does anyone have P9 working on SMP?  Fernando, can you see if M5 works
> on SMP?  If this works it would seem that the preemptible IRQs are the
> problem.

It worked for me on an SMP G5, but it would depend on which drivers
are used; some use synchronize_irq() more than others.

IIRC, though, M5 didn't have the IO-APIC fixes, so that's not likely
to work well on SMP either.

-Scott

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Lee Revell]

On Tue, 2004-08-24 at 02:14, Ingo Molnar wrote:

>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> 

Hmm, it seems that those strange ~1ms latencies are back.  This was
triggered by mounting an NTFS volume:

http://krustophenia.net/testresults.php?dataset=2.6.8.1-P9#/var/www/2.6.8.1-P9/trace5.txt

Lee

Re: [patch] PPC/PPC64 port of voluntary preempt patch

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-08-25 at 20:17, Lee Revell wrote:
> On Tue, 2004-08-24 at 15:51, Scott Wood wrote:
> > On Mon, Aug 23, 2004 at 06:18:16PM -0400, Scott Wood wrote:
> > > I have attached a port of the voluntary preempt patch to PPC and
> > > PPC64.  The patch is against P7, but it applies against P8 as well.
> > > I've tested it on a dual G5 Mac, both in uniprocessor and SMP.
> > > Some notes on changes to the generic part of the patch/existing
> > > generic code:
> > 
> > Another thing that I forgot to mention is that I have some doubts as
> > to the current generic_synchronize_irq() implementation.  Given that
> > IRQs are now preemptible, a higher priority RT thread calling
> > synchronize_irq can't just spin waiting for the IRQ to complete, as
> > it never will (and it wouldn't be a great idea for non-RT tasks
> > either).  I see that a do_hardirq() call was added, presumably to
> > hurry completion of the interrupt, but is that really safe?  It looks
> > like that could end up re-entering handlers, and you'd still have a
> > partially executed handler after synchronize_irq() finishes (causing
> > not only an extra end() call, but possibly code being executed after
> > it's been unloaded, and other synchronization violations).
> > 
> > If I'm missing something, please let me know, but I don't see a good
> > way to implement it without blocking for the IRQ thread's completion
> > (such as with the per-IRQ waitqueues in M5).
> 
> I think Scott may be on to something.  There are several reports that P9
> does not work on SMP machines at all - it either doesn't boot, locks up
> the first time there is heavy IRQ activity (starting KDE), or locks up
> as soon as the first RT process is run.  This is exactly the behavior
> that would be expected if Scott is correct.  See this thread:
> 
> http://ccrma-mail.stanford.edu/pipermail/planetccrma/2004-August/005899.html
> 
> Does anyone have P9 working on SMP?  Fernando, can you see if M5 works
> on SMP?  If this works it would seem that the preemptible IRQs are the
> problem.

Sorry, I could not get SMP 2.6.8.1 + voluntary M5 to boot on my dual
Athlon test system. Again problems with interrupts but worse than P9,
this time acpi=off or pci=noacpi did not help (I can boot single user,
but the machine hang in the network startup - or if I disable that,
later on X startup). I saw two messages, one "irq 9: nobody cared!" and
then "Disabling IRQ # 9" (that's the one for the network card). On a
different boot:
  Badness in free_irq at  .... irq.c
free_irq
load_balance_new_idle
floppy_release_irq_and_dma
set_dor
motor_off_callback
...

So I could not get to the point where I could test jack and SCHED_FIFO
processes. 

-- Fernando

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Lee Revell]

On Thu, 2004-08-26 at 17:39, Lee Revell wrote:
> On Tue, 2004-08-24 at 02:14, Ingo Molnar wrote:
> 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> > 
> 
> Hmm, it seems that those strange ~1ms latencies are back.  This was
> triggered by mounting an NTFS volume:
> 
> http://krustophenia.net/testresults.php?dataset=2.6.8.1-P9#/var/www/2.6.8.1-P9/trace5.txt
> 

I think vger was messed up yesterday, as this did not get through the
first time I sent it, and I did not get any messages from the list for
4-5 hours last night.

I am seeing large latencies (600-2000 usec) latencies in
dcache_readdir.  This started when the machine became a Samba server and
the dcache presumably got large.  Traces are at the above url (8 and 9 I
believe).  I think this patch fixes it.

--- fs/libfs.c~	2004-08-14 06:54:47.000000000 -0400
+++ fs/libfs.c	2004-08-27 00:44:17.000000000 -0400
@@ -140,6 +140,7 @@
 			}
 			for (p=q->next; p != &dentry->d_subdirs; p=p->next) {
 				struct dentry *next;
+				voluntary_resched_lock(&dcache_lock);
 				next = list_entry(p, struct dentry, d_child);
 				if (d_unhashed(next) || !next->d_inode)
 					continue;


Lee

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> I am seeing large latencies (600-2000 usec) latencies in
> dcache_readdir.  This started when the machine became a Samba server
> and the dcache presumably got large.  Traces are at the above url (8
> and 9 I believe).  I think this patch fixes it.
> 
> --- fs/libfs.c~	2004-08-14 06:54:47.000000000 -0400
> +++ fs/libfs.c	2004-08-27 00:44:17.000000000 -0400
> @@ -140,6 +140,7 @@
>  			}
>  			for (p=q->next; p != &dentry->d_subdirs; p=p->next) {
>  				struct dentry *next;
> +				voluntary_resched_lock(&dcache_lock);
>  				next = list_entry(p, struct dentry, d_child);
>  				if (d_unhashed(next) || !next->d_inode)
>  					continue;

In this loop we are iterating over the child-directories of this
directory. In the next line (not shown in this patch) we drop the
dcache_lock - so the issue is the 'continue' - where we skip already
deleted entries. Are you positive this fixes the latencies you are
seeing? The 'deleted entries' situation ought to be relatively rare.

	Ingo

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q0

[Ingo Molnar]

i've uploaded the -Q0 patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q0

note that since -bk4 doesnt exist yet, i've uploaded a patch that brings
2.6.8.1 up to BK-curr:

  http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

apply this patch to 2.6.8.1 before applying the -Q0 patch.

Changes:

there are a number of fundamental changes in the -Q0, of both structural
and functional nature.

Structural changes:

Linus' current BK tree (what will be 2.6.9-rc1-bk4) has just merged most
of the might_sleep() improvements we did for -mm and a bunch of other
changes that were part of the voluntary-preempt patchset. So i've
started a pre-merge cleanup of the voluntary-preempt patchset, to be
able to merge as much of the remaining stuff upstream as possible. This
doesnt (necessarily) mean voluntary-preempt itself will be merged, it
means that the independent latency improvements move out of the
voluntary-preemption umbrella and will go upstream.

About the cleanup:

Firstly, the user controls have changed. There are now 4 independent
flags in /proc/sys/kernel/: kernel_preemption, voluntary_preemption,
softirq_preemption and hardirq_preemption - each default to a value of 1
(enabled). NOTE: levels 2,3 for voluntary_preemption is not valid
anymore, each of the flags can be 0 or 1. The flags control what their
name says, for best latencies one should keep all of them enabled.

Similarly, there are 4 independent options for the .config:
CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS and
CONFIG_PREEMPT_HARDIRQS. (In theory all of these options should compile
independently, but i've only tested all-enabled so far.)

Internally, the voluntary_ prefixed conditional reschedule variants were
replaced by the existing cond_resched(), cond_resched_lock(),
need_resched()/etc. infrastructure.

Functional changes:

i took another look at SMP latencies, the last larger chunk of code that
produced millisec-category latencies. CONFIG_PREEMPT tries to solve some
of the SMP issues but there were still lots of problems remaining: main
problem area is spinlocks nested at multiple levels. If a piece of code
(e.g. the MM or ext3's journalling code) does the following:

	spin_lock(&spinlock_1);
	...
	spin_lock(&spinlock_2);
	...

then even with CONFIG_PREEMPT enabled, current kernels may spin on
spinlock_2 indefinitely. A number of critical sections break their long
paths by using cond_resched_lock(), but this does not break the path on
SMP, because need_resched() is not set in the above case.

(The -mm kernel introduced a couple of patches that try to drop
spinlocks unconditionally at a high frequency: but besides being a
kludge it's also a performance problem, we keep
dropping/waiting/retaking locks quite frequently. That solution also
doesnt solve the problem of cond_resched_lock() not working on SMP.)

to solve the problem i've introduced a new spinlock field,
lock->break_lock, which signals towards the holding CPU that a
spinlock-break is requested by another CPU. This field is only set if a
CPU is spinning in __preempt_spin_lock [at any locking depth], so the
default overhead is zero. I've extended cond_resched_lock() to check for
this flag - in this case we can also save a reschedule. I've added the
lock_need_resched(lock) and need_lockbreak(lock) methods to check for
the need to break out of a critical section.

preliminary results on a dual x86 box show a dramatic reduction in
latencies on SMP - where there used to be 5-10 msec latencies there are
close-to-UP latencies now. But it needs more testing.

the -Q0 patch also adds a number of lock-breaks that are part of the -mm
tree: e.g. the PTY lock-break.

please re-send any patches that i havent merged yet, and re-report
latencies that still occur with -Q0.

	Ingo

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8.1-P9
> 
> Hmm, it seems that those strange ~1ms latencies are back.  This was
> triggered by mounting an NTFS volume:
> 
> http://krustophenia.net/testresults.php?dataset=2.6.8.1-P9#/var/www/2.6.8.1-P9/trace5.txt

this is genuine NTFS overhead.

the 1 msec events you get because the timer fires once every 1 msec, but
this is not irregular. There is a single NTFS function running, which is
profiled nicely by the timer IRQ:

 00010001 0.372ms (+0.372ms): do_IRQ (load_and_init_upcase)
 ...
 00010001 1.374ms (+0.981ms): do_IRQ (load_and_init_upcase)
 ...
 00010001 2.376ms (+0.978ms): do_IRQ (load_and_init_upcase)
 ...
 00000001 2.615ms (+0.216ms): vfree (load_and_init_upcase)

to be able to debug such latencies is one reason why i changed the
do_IRQ() trace-entry to show the interrupted function's name. (it
wouldnt normally, mcount() doesnt reach across IRQ frames.)

load_and_init_upcase() is called by ntfs_fill_super() which is called by
the mount code, which runs under lock_kernel(). It seems NTFS does not
rely on the BKL - could you try the patch below, does it solve the
latency?

	Ingo

--- linux/fs/ntfs/super.c.orig
+++ linux/fs/ntfs/super.c
@@ -2288,6 +2288,8 @@ static int ntfs_fill_super(struct super_
 	vol->fmask = 0177;
 	vol->dmask = 0077;
 
+	unlock_kernel();
+
 	/* Important to get the mount options dealt with now. */
 	if (!parse_options(vol, (char*)opt))
 		goto err_out_now;
@@ -2424,6 +2426,7 @@ static int ntfs_fill_super(struct super_
 		}
 		up(&ntfs_lock);
 		sb->s_export_op = &ntfs_export_ops;
+		lock_kernel();
 		return 0;
 	}
 	ntfs_error(sb, "Failed to allocate root directory.");
@@ -2527,6 +2530,7 @@ iput_tmp_ino_err_out_now:
 	}
 	/* Errors at this stage are irrelevant. */
 err_out_now:
+	lock_kernel();
 	sb->s_fs_info = NULL;
 	kfree(vol);
 	ntfs_debug("Failed, returning -EINVAL.");

Re: [patch] PPC/PPC64 port of voluntary preempt patch

[Ingo Molnar]

* Scott Wood <scott@timesys.com> wrote:

> Another thing that I forgot to mention is that I have some doubts as
> to the current generic_synchronize_irq() implementation.  Given that
> IRQs are now preemptible, a higher priority RT thread calling
> synchronize_irq can't just spin waiting for the IRQ to complete, as it
> never will (and it wouldn't be a great idea for non-RT tasks either). 
> I see that a do_hardirq() call was added, presumably to hurry
> completion of the interrupt, but is that really safe?  It looks like
> that could end up re-entering handlers, and you'd still have a
> partially executed handler after synchronize_irq() finishes (causing
> not only an extra end() call, but possibly code being executed after
> it's been unloaded, and other synchronization violations).
> 
> If I'm missing something, please let me know, but I don't see a good
> way to implement it without blocking for the IRQ thread's completion
> (such as with the per-IRQ waitqueues in M5).

agreed, this is a hole in generic_synchronize_irq(). I've added
handler-completion waitqueues to my current tree, it will show up in
-Q1.

	Ingo

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q1

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Scott Wood <scott@timesys.com> wrote:
> 
> > If I'm missing something, please let me know, but I don't see a good
> > way to implement it without blocking for the IRQ thread's completion
> > (such as with the per-IRQ waitqueues in M5).
> 
> agreed, this is a hole in generic_synchronize_irq(). I've added
> handler-completion waitqueues to my current tree, it will show up in
> -Q1.

i've uploaded -Q1:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q1

as with -Q0, the following patch has to be applied to 2.6.8.1 first:

  http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

those who still have DRI problems under -Q1 - please unapply the
drm_os_linux.h change, does the fix the lockups?

Changes since -Q0:

- the synchronize_irq() fix - this might help SMP problems.

- adds unlock_kernel() to the NTFS and ext3 mount path, to fix the
  latencies reported by Lee Revell.

	Ingo

Re: [patch] voluntary-preempt-2.6.8.1-P9

[Lee Revell]

On Sat, 2004-08-28 at 03:37, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > I am seeing large latencies (600-2000 usec) latencies in
> > dcache_readdir.  This started when the machine became a Samba server
> > and the dcache presumably got large.  Traces are at the above url (8
> > and 9 I believe).  I think this patch fixes it.
> > 
> > --- fs/libfs.c~	2004-08-14 06:54:47.000000000 -0400
> > +++ fs/libfs.c	2004-08-27 00:44:17.000000000 -0400
> > @@ -140,6 +140,7 @@
> >  			}
> >  			for (p=q->next; p != &dentry->d_subdirs; p=p->next) {
> >  				struct dentry *next;
> > +				voluntary_resched_lock(&dcache_lock);
> >  				next = list_entry(p, struct dentry, d_child);
> >  				if (d_unhashed(next) || !next->d_inode)
> >  					continue;
> 
> In this loop we are iterating over the child-directories of this
> directory. In the next line (not shown in this patch) we drop the
> dcache_lock - so the issue is the 'continue' - where we skip already
> deleted entries. Are you positive this fixes the latencies you are
> seeing? The 'deleted entries' situation ought to be relatively rare.

No, I am not sure this fixes the problem.  This is a pretty rare one, I
only saw it twice.  I have not seen it since making the above change,
but this doesn't mean anything.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q0

[Felipe Alfaro Solana]

On Saturday 28 August 2004 14:03, Ingo Molnar wrote:

> Similarly, there are 4 independent options for the .config:
> CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS and
> CONFIG_PREEMPT_HARDIRQS. (In theory all of these options should compile
> independently, but i've only tested all-enabled so far.)

I must be missing something, but after applying diff-bk-040828-2.6.8.1.bz2 and 
voluntary-preempt-2.6.9-rc1-bk4-Q1 on top of 2.6.8.1, I'm unable to find 
neither CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS, nor 
CONFIG_PREEMPT_HARDIRQS.

Any ideas are welcome.

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q0

[K.R. Foley]

Felipe Alfaro Solana wrote:
> On Saturday 28 August 2004 14:03, Ingo Molnar wrote:
> 
> 
>>Similarly, there are 4 independent options for the .config:
>>CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS and
>>CONFIG_PREEMPT_HARDIRQS. (In theory all of these options should compile
>>independently, but i've only tested all-enabled so far.)
> 
> 
> I must be missing something, but after applying diff-bk-040828-2.6.8.1.bz2 and 
> voluntary-preempt-2.6.9-rc1-bk4-Q1 on top of 2.6.8.1, I'm unable to find 
> neither CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS, nor 
> CONFIG_PREEMPT_HARDIRQS.
> 
> Any ideas are welcome.

Looks like all of these config options are missing from Q1 also. I was 
just looking myself.

kr

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q0

[Lee Revell]

On Sat, 2004-08-28 at 12:50, K.R. Foley wrote:
> Felipe Alfaro Solana wrote:
> > On Saturday 28 August 2004 14:03, Ingo Molnar wrote:
> > 
> > 
> >>Similarly, there are 4 independent options for the .config:
> >>CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS and
> >>CONFIG_PREEMPT_HARDIRQS. (In theory all of these options should compile
> >>independently, but i've only tested all-enabled so far.)
> > 
> > 
> > I must be missing something, but after applying diff-bk-040828-2.6.8.1.bz2 and 
> > voluntary-preempt-2.6.9-rc1-bk4-Q1 on top of 2.6.8.1, I'm unable to find 
> > neither CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS, nor 
> > CONFIG_PREEMPT_HARDIRQS.
> > 
> > Any ideas are welcome.
> 
> Looks like all of these config options are missing from Q1 also. I was 
> just looking myself.
> 

Same results here, none of those config options seem to exist.  I also
get this warning a lot:

include/linux/rwsem.h: In function `down_read':
include/linux/rwsem.h:43: warning: implicit declaration of function `cond_resched'

Lee

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q2

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> > > I must be missing something, but after applying diff-bk-040828-2.6.8.1.bz2 and 
> > > voluntary-preempt-2.6.9-rc1-bk4-Q1 on top of 2.6.8.1, I'm unable to find 
> > > neither CONFIG_PREEMPT_VOLUNTARY, CONFIG_PREEMPT_SOFTIRQS, nor 
> > > CONFIG_PREEMPT_HARDIRQS.
> > > 
> > > Any ideas are welcome.
> > 
> > Looks like all of these config options are missing from Q1 also. I was 
> > just looking myself.
> > 
> 
> Same results here, none of those config options seem to exist.  I also
> get this warning a lot:
> 
> include/linux/rwsem.h: In function `down_read':
> include/linux/rwsem.h:43: warning: implicit declaration of function `cond_resched'

there's a Kconfig chunk missing from the Q0/Q1 patches, i've uploaded Q2
that fixes this:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q2

ontop of:

  http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q2

[Lee Revell]

On Sat, 2004-08-28 at 15:44, Ingo Molnar wrote:

> there's a Kconfig chunk missing from the Q0/Q1 patches, i've uploaded Q2

Still not quite right:

  HOSTLD  scripts/mod/modpost
  CC      arch/i386/kernel/asm-offsets.s
In file included from arch/i386/kernel/asm-offsets.c:7:
include/linux/sched.h: In function `lock_need_resched':
include/linux/sched.h:983: error: structure has no member named `break_lock'
make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1
make: *** [arch/i386/kernel/asm-offsets.s] Error 2

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q2

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Sat, 2004-08-28 at 15:44, Ingo Molnar wrote:
> 
> > there's a Kconfig chunk missing from the Q0/Q1 patches, i've uploaded Q2
> 
> Still not quite right:
> 
>   HOSTLD  scripts/mod/modpost
>   CC      arch/i386/kernel/asm-offsets.s
> In file included from arch/i386/kernel/asm-offsets.c:7:
> include/linux/sched.h: In function `lock_need_resched':
> include/linux/sched.h:983: error: structure has no member named `break_lock'
> make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1
> make: *** [arch/i386/kernel/asm-offsets.s] Error 2

you probably have CONFIG_PREEMPT_VOLUNTARY disabled in the .config?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q2

[Lee Revell]

On Sat, 2004-08-28 at 16:04, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Sat, 2004-08-28 at 15:44, Ingo Molnar wrote:
> > 
> > > there's a Kconfig chunk missing from the Q0/Q1 patches, i've uploaded Q2
> > 
> > Still not quite right:
> > 
> >   HOSTLD  scripts/mod/modpost
> >   CC      arch/i386/kernel/asm-offsets.s
> > In file included from arch/i386/kernel/asm-offsets.c:7:
> > include/linux/sched.h: In function `lock_need_resched':
> > include/linux/sched.h:983: error: structure has no member named `break_lock'
> > make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1
> > make: *** [arch/i386/kernel/asm-offsets.s] Error 2
> 
> you probably have CONFIG_PREEMPT_VOLUNTARY disabled in the .config?
> 

Nope:

# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
# CONFIG_X86_UP_APIC is not set

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q2

[Daniel Schmitt]

On Saturday 28 August 2004 21:44, Ingo Molnar wrote:
>
> there's a Kconfig chunk missing from the Q0/Q1 patches, i've uploaded Q2
> that fixes this:
>
This breaks here unless CONFIG_SMP is defined, with the following error:

  CC      arch/i386/kernel/asm-offsets.s
In file included from arch/i386/kernel/asm-offsets.c:7:
include/linux/sched.h: In function `lock_need_resched':
include/linux/sched.h:983: error: structure has no member named `break_lock'

Probably missing a check for CONFIG_SMP around the need_lockbreak defines in 
sched.h, and maybe also in cond_resched_lock().

Daniel.

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Ingo Molnar]

* Daniel Schmitt <pnambic@unu.nu> wrote:

> > there's a Kconfig chunk missing from the Q0/Q1 patches, i've uploaded Q2
> > that fixes this:
> >
> This breaks here unless CONFIG_SMP is defined, with the following error:
> 
>   CC      arch/i386/kernel/asm-offsets.s
> In file included from arch/i386/kernel/asm-offsets.c:7:
> include/linux/sched.h: In function `lock_need_resched':
> include/linux/sched.h:983: error: structure has no member named `break_lock'
> 
> Probably missing a check for CONFIG_SMP around the need_lockbreak
> defines in sched.h, and maybe also in cond_resched_lock().

doh - right indeed. -Q3 has this fixed, it is at:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q3

ontop of the usual:

  http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

        Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Lee Revell]

On Sat, 2004-08-28 at 16:31, Ingo Molnar wrote:
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q3
> 

I get this error: 

WARNING: /lib/modules/2.6.9-rc1-Q3/kernel/fs/ntfs/ntfs.ko needs unknown symbol unlock_kernel
WARNING: /lib/modules/2.6.9-rc1-Q3/kernel/fs/ntfs/ntfs.ko needs unknown symbol lock_kernel

I believe this is the correct fix:

--- fs/ntfs/super.c~	2004-08-28 16:31:33.000000000 -0400
+++ fs/ntfs/super.c	2004-08-28 17:08:11.000000000 -0400
@@ -29,6 +29,7 @@
 #include <linux/buffer_head.h>
 #include <linux/vfs.h>
 #include <linux/moduleparam.h>
+#include <linux/smp_lock.h>
 
 #include "ntfs.h"
 #include "sysctl.h"

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Sat, 2004-08-28 at 16:31, Ingo Molnar wrote:
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q3
> > 
> 
> I get this error: 
> 
> WARNING: /lib/modules/2.6.9-rc1-Q3/kernel/fs/ntfs/ntfs.ko needs unknown symbol unlock_kernel
> WARNING: /lib/modules/2.6.9-rc1-Q3/kernel/fs/ntfs/ntfs.ko needs unknown symbol lock_kernel
> 
> I believe this is the correct fix:
> 
> --- fs/ntfs/super.c~	2004-08-28 16:31:33.000000000 -0400
> +++ fs/ntfs/super.c	2004-08-28 17:08:11.000000000 -0400
> @@ -29,6 +29,7 @@
>  #include <linux/buffer_head.h>
>  #include <linux/vfs.h>
>  #include <linux/moduleparam.h>
> +#include <linux/smp_lock.h>
>  
>  #include "ntfs.h"
>  #include "sysctl.h"

ok, will add this to -Q4.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Lee Revell]

On Sat, 2004-08-28 at 17:13, Ingo Molnar wrote:
> ok, will add this to -Q4.
> 

Hrm, Q3 broke my PS/2 keyboard.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Lee Revell]

On Sat, 2004-08-28 at 17:16, Lee Revell wrote:
> On Sat, 2004-08-28 at 17:13, Ingo Molnar wrote:
> > ok, will add this to -Q4.
> > 
> 
> Hrm, Q3 broke my PS/2 keyboard.
> 

The problem goes away when I disable CONFIG_PREEMPT_HARDIRQS.  In both
cases CONFIG_PREEMPT_SOFTIRQS was enabled.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Lee Revell]

On Sat, 2004-08-28 at 19:51, Lee Revell wrote:
> On Sat, 2004-08-28 at 17:16, Lee Revell wrote:
> > On Sat, 2004-08-28 at 17:13, Ingo Molnar wrote:
> > > ok, will add this to -Q4.
> > > 
> > 
> > Hrm, Q3 broke my PS/2 keyboard.
> > 

Some more info:

This bug is 100% reproducible.  During boot, as soon as the i8042 driver
is loaded:

serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0

the keyboard freezes, with 'Num Lock' stuck on.

The problem only occurs when CONFIG_PREEMPT_HARDIRQS=y.  Works fine
otherwise.

/proc/interrupts:

           CPU0       
  0:     509819          XT-PIC  timer
  1:       1649          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  8:          4          XT-PIC  rtc
 10:          0          XT-PIC  uhci_hcd, EMU10K1
 11:      24394          XT-PIC  uhci_hcd, eth0
 12:          0          XT-PIC  uhci_hcd
 14:          1          XT-PIC  ide0
 15:      12864          XT-PIC  ide1
NMI:          0 
ERR:          0

Lee

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> Some more info:
> 
> This bug is 100% reproducible.  During boot, as soon as the i8042 driver
> is loaded:
> 
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> input: AT Translated Set 2 keyboard on isa0060/serio0
> 
> the keyboard freezes, with 'Num Lock' stuck on.
> 
> The problem only occurs when CONFIG_PREEMPT_HARDIRQS=y.  Works fine
> otherwise.

i suspect it's the generic_synchronize_irq() change. Does -Q4 boot?:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q4

-Q4 reverts this change. (this doesnt solve the problems Scott noticed
though.)

another solution would be to boot Q3 with preempt_hardirqs=0 and then
turn on threading for all IRQs but the keyboard.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[Lee Revell]

On Sun, 2004-08-29 at 01:43, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > Some more info:
> > 
> > This bug is 100% reproducible.  During boot, as soon as the i8042 driver
> > is loaded:
> > 
> > serio: i8042 AUX port at 0x60,0x64 irq 12
> > serio: i8042 KBD port at 0x60,0x64 irq 1
> > input: AT Translated Set 2 keyboard on isa0060/serio0
> > 
> > the keyboard freezes, with 'Num Lock' stuck on.
> > 
> > The problem only occurs when CONFIG_PREEMPT_HARDIRQS=y.  Works fine
> > otherwise.
> 
> i suspect it's the generic_synchronize_irq() change. Does -Q4 boot?:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q4
> 
> -Q4 reverts this change. (this doesnt solve the problems Scott noticed
> though.)
> 
> another solution would be to boot Q3 with preempt_hardirqs=0 and then
> turn on threading for all IRQs but the keyboard.
> 

Nope, neither of these fixes the problem.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Matt Heler]

I had this ambitional feeling to port this over to the mm tree. 

So here's a link for Q3 .. 

http://mobius.lpbproductions.com/kernel/voluntary-preempt-2.6.9-rc1-mm1-Q3

I test compiled this patch fine. I havent had time yet to boot up onto it. But 
I'm fairly positive it will work.

Matt H.

On Saturday 28 August 2004 1:31 pm, Ingo Molnar wrote:
> * Daniel Schmitt <pnambic@unu.nu> wrote:
> > > there's a Kconfig chunk missing from the Q0/Q1 patches, i've uploaded
> > > Q2 that fixes this:
> >
> > This breaks here unless CONFIG_SMP is defined, with the following error:
> >
> >   CC      arch/i386/kernel/asm-offsets.s
> > In file included from arch/i386/kernel/asm-offsets.c:7:
> > include/linux/sched.h: In function `lock_need_resched':
> > include/linux/sched.h:983: error: structure has no member named
> > `break_lock'
> >
> > Probably missing a check for CONFIG_SMP around the need_lockbreak
> > defines in sched.h, and maybe also in cond_resched_lock().
>
> doh - right indeed. -Q3 has this fixed, it is at:
>
>  
> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-
>Q3
>
> ontop of the usual:
>
>   http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2
>
>         Ingo
>
> -
> 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/

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> > > The problem only occurs when CONFIG_PREEMPT_HARDIRQS=y.  Works fine
> > > otherwise.
> > 
> > i suspect it's the generic_synchronize_irq() change. Does -Q4 boot?:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q4
> > 
> > -Q4 reverts this change. (this doesnt solve the problems Scott noticed
> > though.)
> > 
> > another solution would be to boot Q3 with preempt_hardirqs=0 and then
> > turn on threading for all IRQs but the keyboard.
> > 
> 
> Nope, neither of these fixes the problem.

the correct boot parameter is hardirq-preempt=0.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> > -Q4 reverts this change. (this doesnt solve the problems Scott noticed
> > though.)
> > 
> > another solution would be to boot Q3 with preempt_hardirqs=0 and then
> > turn on threading for all IRQs but the keyboard.
> > 
> 
> Nope, neither of these fixes the problem.

i can reproduce a PS2 keyboard problem on a testsystem. It's not clear
yet what the issue is, something in the atkbd.c code changed between
2.6.8.1 and 2.6.9-rc1-bk4 that broke IRQ redirection - even using the P9
hardirq.c code doesnt fix the problem. Investigating it.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[K.R. Foley]

Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> 
>>>-Q4 reverts this change. (this doesnt solve the problems Scott noticed
>>>though.)
>>>
>>>another solution would be to boot Q3 with preempt_hardirqs=0 and then
>>>turn on threading for all IRQs but the keyboard.
>>>
>>
>>Nope, neither of these fixes the problem.
> 
> 
> i can reproduce a PS2 keyboard problem on a testsystem. It's not clear
> yet what the issue is, something in the atkbd.c code changed between
> 2.6.8.1 and 2.6.9-rc1-bk4 that broke IRQ redirection - even using the P9
> hardirq.c code doesnt fix the problem. Investigating it.
> 
> 	Ingo
> 

Something of interest on this, maybe:

Here is the (pertinent) log of the system booting:

Aug 29 09:32:50 daffy kernel: requesting new irq thread for IRQ1...
Aug 29 09:32:50 daffy kernel: atkbd.c: Spurious ACK on isa0060/serio1. 
Some program, like XFree86, might be trying access hardware directly.
Aug 29 09:32:50 daffy kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, 
MD_SB_DISKS=27
Aug 29 09:32:50 daffy kernel: IRQ#1 thread started up.

And some further entries:

Aug 29 16:48:50 daffy kernel: atkbd.c: Spurious NAK on isa0060/serio1. 
Some program, like XFree86, might be trying access hardware directly.
Aug 29 16:48:50 daffy kernel: atkbd.c: Unknown key pressed (raw set 2, 
code 0x0 on isa0060/serio1).
Aug 29 16:48:50 daffy kernel: atkbd.c: Use 'setkeycodes 00 <keycode>' to 
make it known.
Aug 29 16:48:50 daffy kernel: atkbd.c: Unknown key pressed (raw set 2, 
code 0x18 on isa0060/serio1).
Aug 29 16:48:50 daffy kernel: atkbd.c: Use 'setkeycodes 18 <keycode>' to 
make it known.

I get the "Unknown key pressed" and "Use 'setkeycodes" messages whenever 
I press a key on the keyboard. I don't see very many of the "Spurious 
NAK" messages though.

kr

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q1

[Fernando Pablo Lopez-Lezcano]

On Sat, 2004-08-28 at 06:01, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > * Scott Wood <scott@timesys.com> wrote:
> > 
> > > If I'm missing something, please let me know, but I don't see a good
> > > way to implement it without blocking for the IRQ thread's completion
> > > (such as with the per-IRQ waitqueues in M5).
> > 
> > agreed, this is a hole in generic_synchronize_irq(). I've added
> > handler-completion waitqueues to my current tree, it will show up in
> > -Q1.
> 
> i've uploaded -Q1:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q1
> 
> as with -Q0, the following patch has to be applied to 2.6.8.1 first:
> 
>   http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2
> 
> those who still have DRI problems under -Q1 - please unapply the
> drm_os_linux.h change, does the fix the lockups?

I managed to do a few quick tests yesterday of voluntary Q3:

SMP kernel on UP machine (Athlon64): hangs during boot, goes a little
further than before but hangs anyway:

requesting new irq thread for IRQ169
ata1: dev 0 ATA, max UDMA/133 ...
IRQ#169 thread started up
ata1: dev 0 configured for UDMA/133 ...
scsi0: sata_promise
ata2: dev 0 ATA ...
  --- hangs ---

SMP kernel on SMP machine (dual Athlon):
softirq-preempt=0 hardirq-preempt=0 acpi=on: hangs
  afaik hang happens when something needs interrupts, first culprit in
  my machine is eth0, if I disable it I can go further ahead and boot
  but alsa has timeouts, presumably because it is not getting
  interrupts.
softirq-preempt=0 hardirq-preempt=0 acpi=off: boots normally, 
  jack, glxgears work fine (but high latency spikes)
softirq-preempt=1 hardirq-preempt=1 acpi=off: boots normally,
  jack works fine, glxgears hangs machine after a while
Sorry I was not able to check all permutations, I was late and stopped
rebooting the machine :-) I think I did one more test with sort=1,
hard=1, acpi=off and did not manage to hang the machine. 

-- Fernando

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[K.R. Foley]

K.R. Foley wrote:
> Ingo Molnar wrote:
> 
>> * Lee Revell <rlrevell@joe-job.com> wrote:
>>
>>
>>>> -Q4 reverts this change. (this doesnt solve the problems Scott noticed
>>>> though.)
>>>>
>>>> another solution would be to boot Q3 with preempt_hardirqs=0 and then
>>>> turn on threading for all IRQs but the keyboard.
>>>>
>>>
>>> Nope, neither of these fixes the problem.
>>
>>
>>
>> i can reproduce a PS2 keyboard problem on a testsystem. It's not clear
>> yet what the issue is, something in the atkbd.c code changed between
>> 2.6.8.1 and 2.6.9-rc1-bk4 that broke IRQ redirection - even using the P9
>> hardirq.c code doesnt fix the problem. Investigating it.
>>
>>     Ingo
>>

Actually after doing a diff on atkbd, there don't seem to be any 
differences between 2.6.9-rc1 and 2.6.8.1. :( Also after looking back 
through my logs some things worth noting here:

> 
> Something of interest on this, maybe:
> 
> Here is the (pertinent) log of the system booting:
> 
> Aug 29 09:32:50 daffy kernel: requesting new irq thread for IRQ1...
> Aug 29 09:32:50 daffy kernel: atkbd.c: Spurious ACK on isa0060/serio1. 
> Some program, like XFree86, might be trying access hardware directly.

These have been here for a while.

> Aug 29 09:32:50 daffy kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, 
> MD_SB_DISKS=27
> Aug 29 09:32:50 daffy kernel: IRQ#1 thread started up.
> 
> And some further entries:
> 
> Aug 29 16:48:50 daffy kernel: atkbd.c: Spurious NAK on isa0060/serio1. 
> Some program, like XFree86, might be trying access hardware directly.
> Aug 29 16:48:50 daffy kernel: atkbd.c: Unknown key pressed (raw set 2, 
> code 0x0 on isa0060/serio1).
> Aug 29 16:48:50 daffy kernel: atkbd.c: Use 'setkeycodes 00 <keycode>' to 
> make it known.
> Aug 29 16:48:50 daffy kernel: atkbd.c: Unknown key pressed (raw set 2, 
> code 0x18 on isa0060/serio1).
> Aug 29 16:48:50 daffy kernel: atkbd.c: Use 'setkeycodes 18 <keycode>' to 
> make it known.

Looking at the messages above, it appears to me that this is being 
detected as an AT keyboard (or default) instead of a PS/2. Could this be 
a problem?

> 
> I get the "Unknown key pressed" and "Use 'setkeycodes" messages whenever 
> I press a key on the keyboard. I don't see very many of the "Spurious 
> NAK" messages though.
> 
> kr

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

i've uploaded -Q5 to:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5

ontop of:

  http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

-Q5 should fix the PS2 problems and the early boot problems, and it
might even fix the USB, ACPI and APIC problems some people were
reporting.

There were a number of bugs that led to the PS2 problems:

 - a change to __cond_resched() in the -Q series caused the starvation
   of the IRQ1 and IRQ12 threads during init - causing a silent timeout
   and misdetection in the ps2 driver(s).

 - even with the starvation bug fixed, we must set system_state to
   SCHEDULER_OK only once the init thread has started - otherwise the
   idle thread might hang during bootup.

 - the redirected IRQ handling now matches that of non-redirected IRQs
   better, the outer loop in generic_handle_IRQ has been flattened.

i also re-added the synchronize_irq() fix, it was not causing the PS2
problems.

	Ingo

voluntary-preempt-2.6.8.1-P9 : big latency when logging on console

[P.O. Gaillard]

Hello,

I have a 1.6ms latency every time I log in with P9.

Here are the traces. The PC is a P4@3GHz with half a gigabyte of memory and a 
SuperMicro i875p motherboard. The graphics board is integrated which might be 
relevant to this issue since I see vt_ioctl in the backtrace.

I can reproduce the problem every time I try to.

    thank you for your help,

	Pierre-Olivier Gaillard



Aug 30 11:17:40 canopus kernel: (setfont/2332): new 1647 us maximum-latency 
critical section.
Aug 30 11:17:40 canopus kernel:  => started at: <voluntary_resched+0x35/0x70>
Aug 30 11:17:40 canopus kernel:  => ended at:   <voluntary_resched+0x35/0x70>
Aug 30 11:17:40 canopus kernel:  [<c015a0e4>] check_preempt_timing+0x1a4/0x240
Aug 30 11:17:40 canopus kernel:  [<c03aca95>] voluntary_resched+0x35/0x70
Aug 30 11:17:40 canopus kernel:  [<c03aca95>] voluntary_resched+0x35/0x70
Aug 30 11:17:40 canopus kernel:  [<c015a1b6>] touch_preempt_timing+0x36/0x40
Aug 30 11:17:40 canopus kernel:  [<c015a1b6>] touch_preempt_timing+0x36/0x40
Aug 30 11:17:40 canopus kernel:  [<c03aca95>] voluntary_resched+0x35/0x70
Aug 30 11:17:40 canopus kernel:  [<c0229b61>] copy_to_user+0x31/0x90
Aug 30 11:17:40 canopus kernel:  [<c026f143>] vt_ioctl+0x1433/0x1b80
Aug 30 11:17:40 canopus kernel:  [<c01a1027>] .text.lock.pipe+0xf/0xc8
Aug 30 11:17:40 canopus kernel:  [<c0174714>] handle_mm_fault+0x154/0x360
Aug 30 11:17:40 canopus kernel:  [<c015a119>] check_preempt_timing+0x1d9/0x240
Aug 30 11:17:40 canopus kernel:  [<c015a2b8>] sub_preempt_count+0x48/0x60
Aug 30 11:17:40 canopus kernel:  [<c018cd43>] fget+0xe3/0x180
Aug 30 11:17:40 canopus kernel:  [<c026dd10>] vt_ioctl+0x0/0x1b80
Aug 30 11:17:40 canopus kernel:  [<c02668ad>] tty_ioctl+0x57d/0x670
Aug 30 11:17:40 canopus kernel:  [<c01a8cdd>] sys_ioctl+0x23d/0x400
Aug 30 11:17:40 canopus kernel:  [<c018ba10>] sys_read+0x50/0x80
Aug 30 11:17:40 canopus kernel:  [<c0107bfd>] sysenter_past_esp+0x52/0x71

preemption latency trace v1.0.2
-------------------------------
  latency: 1647 us, entries: 82 (82)
     -----------------
     | task: setfont/2332, uid:0 nice:0 policy:0 rt_prio:0
     -----------------
  => started at: voluntary_resched+0x35/0x70
  => ended at:   voluntary_resched+0x35/0x70
=======>
00000001 0.000ms (+0.000ms): touch_preempt_timing (voluntary_resched)
00000001 0.000ms (+0.000ms): vgacon_font_set (con_font_set)
00000001 0.000ms (+0.000ms): vgacon_do_font_op (vgacon_font_set)
00010001 0.084ms (+0.083ms): do_IRQ (vgacon_do_font_op)
00010002 0.084ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010002 0.084ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010001 0.084ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010001 0.084ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010002 0.085ms (+0.000ms): mark_offset_pmtmr (timer_interrupt)
00010002 0.091ms (+0.006ms): do_timer (timer_interrupt)
00010002 0.091ms (+0.000ms): update_process_times (do_timer)
00010002 0.091ms (+0.000ms): update_one_process (update_process_times)
00010002 0.091ms (+0.000ms): run_local_timers (update_process_times)
00010002 0.091ms (+0.000ms): raise_softirq (update_process_times)
00010002 0.092ms (+0.000ms): scheduler_tick (update_process_times)
00010002 0.092ms (+0.000ms): sched_clock (scheduler_tick)
00010002 0.092ms (+0.000ms): update_wall_time (do_timer)
00010002 0.092ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010002 0.093ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010002 0.093ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00000002 0.093ms (+0.000ms): do_softirq (do_IRQ)
00000002 0.093ms (+0.000ms): __do_softirq (do_softirq)
00000002 0.093ms (+0.000ms): wake_up_process (do_softirq)
00000002 0.094ms (+0.000ms): try_to_wake_up (wake_up_process)
00000002 0.094ms (+0.000ms): task_rq_lock (try_to_wake_up)
00000003 0.094ms (+0.000ms): activate_task (try_to_wake_up)
00000003 0.094ms (+0.000ms): sched_clock (activate_task)
00000003 0.094ms (+0.000ms): recalc_task_prio (activate_task)
00000003 0.094ms (+0.000ms): effective_prio (recalc_task_prio)
00000003 0.094ms (+0.000ms): enqueue_task (activate_task)
00000002 0.095ms (+0.000ms): preempt_schedule (try_to_wake_up)
00000001 0.513ms (+0.418ms): smp_apic_timer_interrupt (vgacon_do_font_op)
00010001 0.513ms (+0.000ms): profile_hook (smp_apic_timer_interrupt)
00010002 0.513ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 0.513ms (+0.000ms): preempt_schedule (smp_apic_timer_interrupt)
00000002 0.513ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 0.514ms (+0.000ms): __do_softirq (do_softirq)
00010001 1.083ms (+0.569ms): do_IRQ (vgacon_do_font_op)
00010002 1.083ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010002 1.084ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010001 1.084ms (+0.000ms): preempt_schedule (do_IRQ)
00010001 1.084ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010001 1.084ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010002 1.084ms (+0.000ms): mark_offset_pmtmr (timer_interrupt)
00010002 1.089ms (+0.004ms): preempt_schedule (mark_offset_pmtmr)
00010002 1.091ms (+0.001ms): preempt_schedule (timer_interrupt)
00010002 1.091ms (+0.000ms): do_timer (timer_interrupt)
00010002 1.091ms (+0.000ms): update_process_times (do_timer)
00010002 1.091ms (+0.000ms): update_one_process (update_process_times)
00010002 1.091ms (+0.000ms): run_local_timers (update_process_times)
00010002 1.091ms (+0.000ms): raise_softirq (update_process_times)
00010002 1.091ms (+0.000ms): scheduler_tick (update_process_times)
00010002 1.091ms (+0.000ms): sched_clock (scheduler_tick)
00010003 1.092ms (+0.000ms): dequeue_task (scheduler_tick)
00010003 1.092ms (+0.000ms): effective_prio (scheduler_tick)
00010003 1.092ms (+0.000ms): task_timeslice (scheduler_tick)
00010003 1.092ms (+0.000ms): enqueue_task (scheduler_tick)
00010002 1.092ms (+0.000ms): preempt_schedule (scheduler_tick)
00010002 1.093ms (+0.000ms): update_wall_time (do_timer)
00010002 1.093ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010001 1.093ms (+0.000ms): preempt_schedule (timer_interrupt)
00010002 1.093ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010002 1.093ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00010001 1.093ms (+0.000ms): preempt_schedule (do_IRQ)
00000002 1.094ms (+0.000ms): do_softirq (do_IRQ)
00000002 1.094ms (+0.000ms): __do_softirq (do_softirq)
00000001 1.513ms (+0.418ms): smp_apic_timer_interrupt (vgacon_do_font_op)
00010001 1.513ms (+0.000ms): profile_hook (smp_apic_timer_interrupt)
00010002 1.513ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 1.513ms (+0.000ms): preempt_schedule (smp_apic_timer_interrupt)
00000002 1.513ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 1.513ms (+0.000ms): __do_softirq (do_softirq)
00000001 1.645ms (+0.131ms): preempt_schedule (vgacon_do_font_op)
00000001 1.645ms (+0.000ms): vgacon_adjust_height (vgacon_font_set)
00000001 1.646ms (+0.000ms): release_console_sem (con_font_set)
00000001 1.646ms (+0.000ms): preempt_schedule (release_console_sem)
00000001 1.646ms (+0.000ms): kfree (con_font_set)
00000001 1.646ms (+0.000ms): copy_to_user (vt_ioctl)
00000001 1.646ms (+0.000ms): __might_sleep (copy_to_user)
00000001 1.646ms (+0.000ms): voluntary_resched (copy_to_user)
00000001 1.647ms (+0.000ms): __might_sleep (voluntary_resched)
00000001 1.647ms (+0.000ms): touch_preempt_timing (voluntary_resched)

Re: voluntary-preempt-2.6.8.1-P9 : big latency when logging on console

[Ingo Molnar]

* P.O. Gaillard <pierre-olivier.gaillard@fr.thalesgroup.com> wrote:

> Hello,
> 
> I have a 1.6ms latency every time I log in with P9.

could you try the patch below, ontop of P9? (or ontop of the latest, -Q5
patch)

The problem with font loading is that vt_ioctl runs with the BKL held
(as all ioctls) which disables preemption, but in this case it seems
pretty safe to drop the lock - the vga console has its own spinlock.

	Ingo

--- linux/drivers/video/console/vgacon.c.orig	
+++ linux/drivers/video/console/vgacon.c	
@@ -763,6 +763,7 @@ static int vgacon_do_font_op(struct vgas
 		charmap += 4 * cmapsz;
 #endif
 
+	unlock_kernel();
 	spin_lock_irq(&vga_lock);
 	/* First, the Sequencer */
 	vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x1);
@@ -848,6 +849,7 @@ static int vgacon_do_font_op(struct vgas
 		vga_wattr(state->vgabase, VGA_AR_ENABLE_DISPLAY, 0);	
 	}
 	spin_unlock_irq(&vga_lock);
+	lock_kernel();
 	return 0;
 }
 

Re: [patch] voluntary-preempt-2.6.8.1-P9 : a few submillisecond latencies

[P.O. Gaillard]

Hello,

here are a few submillisecond latencies.

First, the lspci of the machine (which is different from the one I just posted 
about).
http://po.gaillard.free.fr/latency/dell.lspci-v.txt

First, the 3c59x Ethernet card seems to cause 450us latencies :
http://po.gaillard.free.fr/latency/latency_bt.3c59x.txt
http://po.gaillard.free.fr/latency/latency_trace.3c59x.txt

Then the e1000 driver seems to cause 200us latencies :
http://po.gaillard.free.fr/latency/latency_bt.e1000_stats.txt
http://po.gaillard.free.fr/latency/latency_trace.e1000_stats.txt

Since the other machine with an Intel e1000 controller, shows a twice smaller 
latency, I post its lpsci entry for the controller  (note that latency is twice 
smaller) :
02:0a.0 Ethernet controller: Intel Corp. 82541EI Gigabit Ethernet Controller 
(Copper)
         Subsystem: Intel Corp.: Unknown device 1213
         Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 22
         Memory at f2000000 (32-bit, non-prefetchable)
         I/O ports at b400 [size=64]
         Capabilities: [dc] Power Management version 2
         Capabilities: [e4] PCI-X non-bridge device.

  and thank you to Ingo for the speedy response to the console issue. I applied 
the patch and the kernel is compiling.

	P.O. Gaillard

Re: voluntary-preempt-2.6.8.1-P9 : big latency when logging on console

[P.O. Gaillard]

Ingo Molnar wrote:
> * P.O. Gaillard <pierre-olivier.gaillard@fr.thalesgroup.com> wrote:
> 
> 
>>Hello,
>>
>>I have a 1.6ms latency every time I log in with P9.
> 
> 
> could you try the patch below, ontop of P9? (or ontop of the latest, -Q5
> patch)
> 
> The problem with font loading is that vt_ioctl runs with the BKL held
> (as all ioctls) which disables preemption, but in this case it seems
> pretty safe to drop the lock - the vga console has its own spinlock.
> 
Thank you very much. I had to add a "#include <linux/smp_lock.h>" at the start 
of vga_con.c to get it to compile and then :
1) I can login on the console without getting any latency above 100 microseconds.
2) Nothing seems to be broken by your change.

Note: I tested on 2.6.8.1 + P9.

	thanks !

	Pierre-Olivier

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q3

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Sat, 2004-08-28 at 16:31, Ingo Molnar wrote:
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q3
> > 
> 
> I get this error: 
> 
> WARNING: /lib/modules/2.6.9-rc1-Q3/kernel/fs/ntfs/ntfs.ko needs unknown symbol unlock_kernel
> WARNING: /lib/modules/2.6.9-rc1-Q3/kernel/fs/ntfs/ntfs.ko needs unknown symbol lock_kernel
> 
> I believe this is the correct fix:
> 
> --- fs/ntfs/super.c~	2004-08-28 16:31:33.000000000 -0400
> +++ fs/ntfs/super.c	2004-08-28 17:08:11.000000000 -0400
> @@ -29,6 +29,7 @@
>  #include <linux/buffer_head.h>
>  #include <linux/vfs.h>
>  #include <linux/moduleparam.h>
> +#include <linux/smp_lock.h>

indeed. Applied your fix to my tree and it will show up in -Q6.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[Alan Cox]

On Llu, 2004-08-30 at 01:47, K.R. Foley wrote:
> Aug 29 09:32:50 daffy kernel: requesting new irq thread for IRQ1...
> Aug 29 09:32:50 daffy kernel: atkbd.c: Spurious ACK on isa0060/serio1. 
> Some program, like XFree86, might be trying access hardware directly.

This is a known bug in the ps/2 driver layer. The printk can be
triggered by multiple quite valid situations. I've suggested it be
removed several times. Also XFree86 is a trademark so it should be
XFree86(tm) ;)

The later ones are odd. It might be interesting to try turning off USB
legacy support in the BIOS, that may be causing real problems in your
case.

Alan

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Thomas Charbonnel]

Ingo Molnar wrote :
> i've uploaded -Q5 to:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5
> 

Here are the problematic spots for me with Q5:

rtl8139_poll (this one was also present with previous versions of the
patch) :
http://www.undata.org/~thomas/q5_rtl8139.trace

use_module (modprobe) :
preemption latency trace v1.0.2
-------------------------------
 latency: 154 us, entries: 4 (4)
    -----------------
    | task: modprobe/8172, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: resolve_symbol+0x21/0xa0
 => ended at:   resolve_symbol+0x57/0xa0
=======>
00000001 0.000ms (+0.000ms): resolve_symbol (simplify_symbols)
00000001 0.000ms (+0.000ms): __find_symbol (resolve_symbol)
00000001 0.154ms (+0.154ms): use_module (resolve_symbol)
00000001 0.154ms (+0.000ms): sub_preempt_count (resolve_symbol)

and a weird one with do_timer (called from do_IRQ) taking more than 1ms
to complete :
http://www.undata.org/~thomas/do_irq.trace

Thomas

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[Ingo Molnar]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Llu, 2004-08-30 at 01:47, K.R. Foley wrote:
> > Aug 29 09:32:50 daffy kernel: requesting new irq thread for IRQ1...
> > Aug 29 09:32:50 daffy kernel: atkbd.c: Spurious ACK on isa0060/serio1. 
> > Some program, like XFree86, might be trying access hardware directly.
> 
> This is a known bug in the ps/2 driver layer. The printk can be
> triggered by multiple quite valid situations. I've suggested it be
> removed several times. Also XFree86 is a trademark so it should be
> XFree86(tm) ;)

since the message was right during detection it was indication of deeper
trouble - and indeed it was caused by the IRQ1 thread being starved by
init and thus the handler not running at all - the 'spurious ACK' was a
weird (and probably buggy) way of the PS2 layer telling that the
expected IRQ never arrived ...

in any case, this was a bug in the hardirq redirection code.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]


* Thomas Charbonnel <thomas@undata.org> wrote:

> Ingo Molnar wrote :
> > i've uploaded -Q5 to:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5
> > 
> 
> Here are the problematic spots for me with Q5:
> 
> rtl8139_poll (this one was also present with previous versions of the
> patch) :
> http://www.undata.org/~thomas/q5_rtl8139.trace

ok, rx processing latency again. You've set netdev_max_backlog to a low
value, right? I think we can break this particular loop independently of
netdev_max_backlog, could you try the attached patch ontop of -Q5, does
it help?

> =======>
> 00000001 0.000ms (+0.000ms): resolve_symbol (simplify_symbols)
> 00000001 0.000ms (+0.000ms): __find_symbol (resolve_symbol)
> 00000001 0.154ms (+0.154ms): use_module (resolve_symbol)
> 00000001 0.154ms (+0.000ms): sub_preempt_count (resolve_symbol)

seems resolve_symbol() is quite expensive ... no idea how to fix this
one right away, it seems to be pure algorithmic overhead.

> and a weird one with do_timer (called from do_IRQ) taking more than 1ms
> to complete :
> http://www.undata.org/~thomas/do_irq.trace

hm, indeed this is a weird one. 1 msec is too close to the timer 
frequency to be accidental. According to the trace:

 00010000 0.002ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
 00010001 0.002ms (+0.000ms): mark_offset_tsc (timer_interrupt)
 00010001 1.028ms (+1.025ms): do_timer (timer_interrupt)
 00010001 1.028ms (+0.000ms): update_process_times (do_timer)

the latency happened between the beginning of mark_offset_tsc() and the
calling of do_timer() - i.e. the delay happened somewhere within
mark_offset_tsc() itself. Is this an SMP system?

	Ingo

[-- Attachment #2: 2 --]
[-- Type: text/plain, Size: 738 bytes --]

--- linux/net/core/dev.c.orig2	
+++ linux/net/core/dev.c	
@@ -1903,7 +1903,7 @@ static void net_rx_action(struct softirq
 {
 	struct softnet_data *queue = &__get_cpu_var(softnet_data);
 	unsigned long start_time = jiffies;
-	int budget = netdev_max_backlog;
+	int budget = netdev_max_backlog, loops;
 
 	
 	local_irq_disable();
@@ -1926,7 +1926,10 @@ static void net_rx_action(struct softirq
 		dev = list_entry(queue->poll_list.next,
 				 struct net_device, poll_list);
 
-		if (dev->quota <= 0 || dev->poll(dev, &budget)) {
+		loops = 1;
+		if (dev->quota <= 0 || dev->poll(dev, &loops)) {
+			if (loops < 1)
+				budget--;
 			local_irq_disable();
 			list_del(&dev->poll_list);
 			list_add_tail(&dev->poll_list, &queue->poll_list);

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Mon, 2004-08-30 at 05:06, Ingo Molnar wrote:
> i've uploaded -Q5 to:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5

This fixes the PS/2 issue.  Entropy rekeying is still a big problem:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-bk4-Q5#/var/www/2.6.9-rc1-bk4-Q5/trace3.txt

Otherwise, this looks pretty good.  Here is a new one, I got this
starting X:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-bk4-Q5#/var/www/2.6.9-rc1-bk4-Q5/trace2.txt

Lee    

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Mon, 2004-08-30 at 05:06, Ingo Molnar wrote:
> > i've uploaded -Q5 to:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5
> 
> This fixes the PS/2 issue.  Entropy rekeying is still a big problem:
> 
> http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-bk4-Q5#/var/www/2.6.9-rc1-bk4-Q5/trace3.txt

ok. It seems the random driver is _mostly_ in shape latency-wise, except
the IP rekeying visible in the above trace. To solve this problem, could
you try the patch below, ontop of -Q5? It moves the random seed
generation outside of the spinlock - AFAICS the spinlock is only needed
to protect the IP sequence counter itself.

	Ingo

--- linux/drivers/char/random.c.orig
+++ linux/drivers/char/random.c
@@ -2226,17 +2226,18 @@ static unsigned int ip_cnt;
 
 static void rekey_seq_generator(void *private_)
 {
-	struct keydata *keyptr;
+	struct keydata *keyptr, tmp;
 	struct timeval 	tv;
 
 	do_gettimeofday(&tv);
+	get_random_bytes(tmp.secret, sizeof(tmp.secret));
 
 	spin_lock_bh(&ip_lock);
 	keyptr = &ip_keydata[ip_cnt&1];
 
 	keyptr = &ip_keydata[1^(ip_cnt&1)];
 	keyptr->rekey_time = tv.tv_sec;
-	get_random_bytes(keyptr->secret, sizeof(keyptr->secret));
+	memcpy(keyptr->secret, tmp.secret, sizeof(keyptr->secret));
 	keyptr->count = (ip_cnt&COUNT_MASK)<<HASH_BITS;
 	mb();
 	ip_cnt++;

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> Otherwise, this looks pretty good.  Here is a new one, I got this
> starting X:
> 
> http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-bk4-Q5#/var/www/2.6.9-rc1-bk4-Q5/trace2.txt

ok, MTRR setting overhead. It is not quite clear to me which precise
code took so much time, could you stick a couple of 'mcount();' lines
into arch/i386/kernel/cpu/mtrr/generic.c's prepare_set() and
generic_set_mtrr() functions? In particular the wbinvd() [cache
invalidation] instructions within prepare_set() look like a possible
source of latency.

(explicit calls to mcount() can be used to break up latency paths
manually - they wont affect the latency itself, they make the resulting
trace more finegrained.)

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q4

[K.R. Foley]

Alan Cox wrote:
> On Llu, 2004-08-30 at 01:47, K.R. Foley wrote:
> 
>>Aug 29 09:32:50 daffy kernel: requesting new irq thread for IRQ1...
>>Aug 29 09:32:50 daffy kernel: atkbd.c: Spurious ACK on isa0060/serio1. 
>>Some program, like XFree86, might be trying access hardware directly.
> 
> 
> This is a known bug in the ps/2 driver layer. The printk can be
> triggered by multiple quite valid situations. I've suggested it be
> removed several times. Also XFree86 is a trademark so it should be
> XFree86(tm) ;)
> 

Thanks for pointing this out. It would appear that I get this same 
messages when things are working properly, with the exception of getting 
"serio0" when it works vs. "serio1" when it doesn't.

> The later ones are odd. It might be interesting to try turning off USB
> legacy support in the BIOS, that may be causing real problems in your
> case.
> 
I didn't try this because Ingo's latest patch seems to have resolved it.

> Alan
> 
> 
Thanks,

kr

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Peter Zijlstra]

On Mon, 2004-08-30 at 11:06 +0200, Ingo Molnar wrote:
> i've uploaded -Q5 to:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5
> 
> ontop of:
> 
>   http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2
> 
> -Q5 should fix the PS2 problems and the early boot problems, and it
> might even fix the USB, ACPI and APIC problems some people were
> reporting.
> 
> There were a number of bugs that led to the PS2 problems:
> 
>  - a change to __cond_resched() in the -Q series caused the starvation
>    of the IRQ1 and IRQ12 threads during init - causing a silent timeout
>    and misdetection in the ps2 driver(s).
> 
>  - even with the starvation bug fixed, we must set system_state to
>    SCHEDULER_OK only once the init thread has started - otherwise the
>    idle thread might hang during bootup.
> 
>  - the redirected IRQ handling now matches that of non-redirected IRQs
>    better, the outer loop in generic_handle_IRQ has been flattened.
> 
> i also re-added the synchronize_irq() fix, it was not causing the PS2
> problems.
> 
> 	Ingo

Hi Ingo,

this one is great, it's been rock solid for over 24h now. No more SMP
problems for me. Thanks for all the hard work.

Kind regards.

-- 
Peter Zijlstra <a.p.zijlstra@chello.nl>

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 03:06, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > Otherwise, this looks pretty good.  Here is a new one, I got this
> > starting X:
> > 
> > http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-bk4-Q5#/var/www/2.6.9-rc1-bk4-Q5/trace2.txt
> 
> ok, MTRR setting overhead. It is not quite clear to me which precise
> code took so much time, could you stick a couple of 'mcount();' lines
> into arch/i386/kernel/cpu/mtrr/generic.c's prepare_set() and
> generic_set_mtrr() functions? In particular the wbinvd() [cache
> invalidation] instructions within prepare_set() look like a possible
> source of latency.
> 
> (explicit calls to mcount() can be used to break up latency paths
> manually - they wont affect the latency itself, they make the resulting
> trace more finegrained.)

OK, here is the trace after adding a bunch of mcount()s:

preemption latency trace v1.0.2
-------------------------------
 latency: 713 us, entries: 31 (31)
    -----------------
    | task: X/1398, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: cond_resched+0xd/0x40
 => ended at:   sys_ioctl+0xdf/0x290
=======>
00000001 0.000ms (+0.000ms): touch_preempt_timing (cond_resched)
00000001 0.000ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.001ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.002ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.002ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.003ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.004ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.004ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.005ms (+0.000ms): generic_get_mtrr (mtrr_add_page)
00000001 0.005ms (+0.000ms): generic_get_free_region (mtrr_add_page)
00000001 0.006ms (+0.000ms): generic_get_mtrr (generic_get_free_region)
00000001 0.006ms (+0.000ms): generic_get_mtrr (generic_get_free_region)
00000001 0.007ms (+0.000ms): generic_get_mtrr (generic_get_free_region)
00000001 0.008ms (+0.000ms): generic_get_mtrr (generic_get_free_region)
00000001 0.008ms (+0.000ms): set_mtrr (mtrr_add_page)
00000001 0.009ms (+0.000ms): generic_set_mtrr (set_mtrr)
00000001 0.009ms (+0.000ms): generic_set_mtrr (set_mtrr)
00000001 0.009ms (+0.000ms): prepare_set (generic_set_mtrr)
00000002 0.010ms (+0.000ms): prepare_set (generic_set_mtrr)
00000002 0.010ms (+0.000ms): prepare_set (generic_set_mtrr)
00000002 0.375ms (+0.364ms): prepare_set (generic_set_mtrr)
00000002 0.375ms (+0.000ms): prepare_set (generic_set_mtrr)
00000002 0.526ms (+0.150ms): prepare_set (generic_set_mtrr)
00000002 0.534ms (+0.008ms): generic_set_mtrr (set_mtrr)
00000002 0.541ms (+0.007ms): generic_set_mtrr (set_mtrr)
00000002 0.548ms (+0.006ms): generic_set_mtrr (set_mtrr)
00000002 0.552ms (+0.004ms): post_set (generic_set_mtrr)
00000001 0.708ms (+0.155ms): set_mtrr (mtrr_add_page)
00000001 0.713ms (+0.005ms): sub_preempt_count (sys_ioctl)
00000001 0.714ms (+0.000ms): _mmx_memcpy (check_preempt_timing)
00000001 0.715ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)

And here is a patch showing where I added the mcount()s, with some extra
context for clarity:

--- linux-2.6.8.1-Q3-preemptible-hardirqs/arch/i386/kernel/cpu/mtrr/generic.c	2004-08-14 06:55:33.000000000 -0400
+++ linux-2.6.9-rc1-bk4-Q5/arch/i386/kernel/cpu/mtrr/generic.c	2004-08-31 15:05:36.000000000 -0400
@@ -234,28 +234,33 @@
 static spinlock_t set_atomicity_lock = SPIN_LOCK_UNLOCKED;
 
 static void prepare_set(void)
 {
 	unsigned long cr0;
 
 	/*  Note that this is not ideal, since the cache is only flushed/disabled
 	   for this CPU while the MTRRs are changed, but changing this requires
 	   more invasive changes to the way the kernel boots  */
 	spin_lock(&set_atomicity_lock);
 
 	/*  Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
+	mcount();
 	cr0 = read_cr0() | 0x40000000;	/* set CD flag */
+	mcount();
 	wbinvd();
+	mcount();
 	write_cr0(cr0);
+	mcount();
 	wbinvd();
+	mcount(); 
 
 	/*  Save value of CR4 and clear Page Global Enable (bit 7)  */
 	if ( cpu_has_pge ) {
 		cr4 = read_cr4();
 		write_cr4(cr4 & (unsigned char) ~(1 << 7));
 	}
 
 	/* Flush all TLBs via a mov %cr3, %reg; mov %reg, %cr3 */
 	__flush_tlb();
 
 	/*  Save MTRR state */
 	rdmsr(MTRRdefType_MSR, deftype_lo, deftype_hi);
@@ -305,38 +310,41 @@
 static void generic_set_mtrr(unsigned int reg, unsigned long base,
 			     unsigned long size, mtrr_type type)
 /*  [SUMMARY] Set variable MTRR register on the local CPU.
     <reg> The register to set.
     <base> The base address of the region.
     <size> The size of the region. If this is 0 the region is disabled.
     <type> The type of the region.
     <do_safe> If TRUE, do the change safely. If FALSE, safety measures should
     be done externally.
     [RETURNS] Nothing.
 */
 {
+	mcount();
 	prepare_set();
-
+	mcount();
 	if (size == 0) {
 		/* The invalid bit is kept in the mask, so we simply clear the
 		   relevant mask register to disable a range. */
 		wrmsr(MTRRphysMask_MSR(reg), 0, 0);
 	} else {
 		wrmsr(MTRRphysBase_MSR(reg), base << PAGE_SHIFT | type,
 		      (base & size_and_mask) >> (32 - PAGE_SHIFT));
+		mcount();
 		wrmsr(MTRRphysMask_MSR(reg), -size << PAGE_SHIFT | 0x800,
 		      (-size & size_and_mask) >> (32 - PAGE_SHIFT));
 	}
-
+	mcount();
 	post_set();
+	mcount();
 }
 
 int generic_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
 {
 	unsigned long lbase, last;
 
 	/*  For Intel PPro stepping <= 7, must be 4 MiB aligned 
 	    and not touch 0x70000000->0x7003FFFF */
 	if (is_cpu(INTEL) && boot_cpu_data.x86 == 6 &&
 	    boot_cpu_data.x86_model == 1 &&
 	    boot_cpu_data.x86_mask <= 7) {
 		if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {


Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Thomas Charbonnel]

Ingo Molnar wrote :

(...)
> > and a weird one with do_timer (called from do_IRQ) taking more than 1ms
> > to complete :
> > http://www.undata.org/~thomas/do_irq.trace
> 
> hm, indeed this is a weird one. 1 msec is too close to the timer 
> frequency to be accidental. According to the trace:
> 
>  00010000 0.002ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
>  00010001 0.002ms (+0.000ms): mark_offset_tsc (timer_interrupt)
>  00010001 1.028ms (+1.025ms): do_timer (timer_interrupt)
>  00010001 1.028ms (+0.000ms): update_process_times (do_timer)
> 
> the latency happened between the beginning of mark_offset_tsc() and the
> calling of do_timer() - i.e. the delay happened somewhere within
> mark_offset_tsc() itself. Is this an SMP system?
> 
> 	Ingo

It isn't an SMP system, but here are some other traces that can prove
useful :
preemption latency trace v1.0.2
-------------------------------
 latency: 567 us, entries: 35 (35)
    -----------------
    | task: swapper/0, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: do_IRQ+0x19/0x190
 => ended at:   do_IRQ+0x13d/0x190
=======>
00010000 0.000ms (+0.000ms): do_IRQ (common_interrupt)
00010000 0.000ms (+0.000ms): do_IRQ (default_idle)
00010001 0.000ms (+0.000ms): mask_and_ack_8259A (do_IRQ)
00010001 0.002ms (+0.002ms): generic_redirect_hardirq (do_IRQ)
00010000 0.002ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010000 0.002ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010001 0.003ms (+0.000ms): mark_offset_tsc (timer_interrupt)
00010001 0.562ms (+0.559ms): do_timer (timer_interrupt)
00010001 0.562ms (+0.000ms): update_process_times (do_timer)
00010001 0.562ms (+0.000ms): update_one_process (update_process_times)
00010001 0.562ms (+0.000ms): run_local_timers (update_process_times)
00010001 0.562ms (+0.000ms): raise_softirq (update_process_times)
00010001 0.562ms (+0.000ms): scheduler_tick (update_process_times)
00010001 0.562ms (+0.000ms): sched_clock (scheduler_tick)
00010001 0.563ms (+0.000ms): update_wall_time (do_timer)
00010001 0.563ms (+0.000ms): update_wall_time_one_tick
(update_wall_time)
00010001 0.563ms (+0.000ms): profile_tick (timer_interrupt)
00010001 0.563ms (+0.000ms): profile_hook (profile_tick)
00010002 0.563ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 0.564ms (+0.000ms): profile_hit (timer_interrupt)
00010001 0.564ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010001 0.564ms (+0.000ms): end_8259A_irq (do_IRQ)
00010001 0.564ms (+0.000ms): enable_8259A_irq (do_IRQ)
00000001 0.565ms (+0.000ms): do_softirq (do_IRQ)
00000001 0.565ms (+0.000ms): __do_softirq (do_softirq)
00000001 0.565ms (+0.000ms): wake_up_process (do_softirq)
00000001 0.565ms (+0.000ms): try_to_wake_up (wake_up_process)
00000001 0.566ms (+0.000ms): task_rq_lock (try_to_wake_up)
00000002 0.566ms (+0.000ms): activate_task (try_to_wake_up)
00000002 0.566ms (+0.000ms): sched_clock (activate_task)
00000002 0.566ms (+0.000ms): recalc_task_prio (activate_task)
00000002 0.566ms (+0.000ms): effective_prio (recalc_task_prio)
00000002 0.567ms (+0.000ms): enqueue_task (activate_task)
00000001 0.567ms (+0.000ms): preempt_schedule (try_to_wake_up)
00000001 0.567ms (+0.000ms): sub_preempt_count (do_IRQ)

preemption latency trace v1.0.2
-------------------------------
 latency: 624 us, entries: 35 (35)
    -----------------
    | task: swapper/0, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: do_IRQ+0x19/0x190
 => ended at:   do_IRQ+0x13d/0x190
=======>
00010000 0.000ms (+0.000ms): do_IRQ (common_interrupt)
00010000 0.000ms (+0.000ms): do_IRQ (default_idle)
00010001 0.000ms (+0.000ms): mask_and_ack_8259A (do_IRQ)
00010001 0.613ms (+0.612ms): generic_redirect_hardirq (do_IRQ)
00010000 0.613ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010000 0.613ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010001 0.613ms (+0.000ms): mark_offset_tsc (timer_interrupt)
00010001 0.619ms (+0.005ms): do_timer (timer_interrupt)
00010001 0.619ms (+0.000ms): update_process_times (do_timer)
00010001 0.619ms (+0.000ms): update_one_process (update_process_times)
00010001 0.619ms (+0.000ms): run_local_timers (update_process_times)
00010001 0.619ms (+0.000ms): raise_softirq (update_process_times)
00010001 0.619ms (+0.000ms): scheduler_tick (update_process_times)
00010001 0.619ms (+0.000ms): sched_clock (scheduler_tick)
00010001 0.620ms (+0.000ms): update_wall_time (do_timer)
00010001 0.620ms (+0.000ms): update_wall_time_one_tick
(update_wall_time)
00010001 0.620ms (+0.000ms): profile_tick (timer_interrupt)
00010001 0.620ms (+0.000ms): profile_hook (profile_tick)
00010002 0.620ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 0.621ms (+0.000ms): profile_hit (timer_interrupt)
00010001 0.621ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010001 0.621ms (+0.000ms): end_8259A_irq (do_IRQ)
00010001 0.621ms (+0.000ms): enable_8259A_irq (do_IRQ)
00000001 0.622ms (+0.000ms): do_softirq (do_IRQ)
00000001 0.622ms (+0.000ms): __do_softirq (do_softirq)
00000001 0.622ms (+0.000ms): wake_up_process (do_softirq)
00000001 0.622ms (+0.000ms): try_to_wake_up (wake_up_process)
00000001 0.623ms (+0.000ms): task_rq_lock (try_to_wake_up)
00000002 0.623ms (+0.000ms): activate_task (try_to_wake_up)
00000002 0.623ms (+0.000ms): sched_clock (activate_task)
00000002 0.623ms (+0.000ms): recalc_task_prio (activate_task)
00000002 0.623ms (+0.000ms): effective_prio (recalc_task_prio)
00000002 0.623ms (+0.000ms): enqueue_task (activate_task)
00000001 0.624ms (+0.000ms): preempt_schedule (try_to_wake_up)
00000001 0.624ms (+0.000ms): sub_preempt_count (do_IRQ)

As you can see ~1ms was probably an accident, and the latency does not
always come from do_timer. The constant is do_IRQ interrupting the idle
thread.

Thomas

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Thomas Charbonnel <thomas@undata.org> wrote:

> As you can see ~1ms was probably an accident, and the latency does not
> always come from do_timer. The constant is do_IRQ interrupting the
> idle thread.

(do you have any sort of powersaving mode (ACPI/APM) enabled? If yes,
could you try to tune it down as much as possible - disable any
powersaving option in the BIOS and in the .config - kill apmd, etc.)

but i dont think it's powersaving - why would such an overhead show up
in those functions. The only common thing seems to be that both
mark_offset_tsc() and mask_and_ack_8259A() does port IO, which is slow -
but still it shouldnt take ~0.5 msecs!

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> 00000001 0.009ms (+0.000ms): generic_set_mtrr (set_mtrr)
> 00000001 0.009ms (+0.000ms): prepare_set (generic_set_mtrr)

this is the call to prepare_set() [implicit mcount()].

> 00000002 0.010ms (+0.000ms): prepare_set (generic_set_mtrr)

explicit mcount() #1,

> 00000002 0.010ms (+0.000ms): prepare_set (generic_set_mtrr)

#2,

> 00000002 0.375ms (+0.364ms): prepare_set (generic_set_mtrr)

#3. So the latency is this codepath:

+       mcount();
        wbinvd();
+       mcount();

bingo ...

to continue:

> 00000002 0.375ms (+0.000ms): prepare_set (generic_set_mtrr)

mcount #4

> 00000002 0.526ms (+0.150ms): prepare_set (generic_set_mtrr)

#5. This means the following code had the latency:

        write_cr0(cr0);
+       mcount();
        wbinvd();
+       mcount();

the other wbinvd(). Since we didnt execute all that much it didnt take
as much time as the first wbinvd() [the cache was just write-flushed, so
less flushing had to be done second time around].

plus:

 00000002 0.548ms (+0.006ms): generic_set_mtrr (set_mtrr)
 00000002 0.552ms (+0.004ms): post_set (generic_set_mtrr)
 00000001 0.708ms (+0.155ms): set_mtrr (mtrr_add_page)
 00000001 0.713ms (+0.005ms): sub_preempt_count (sys_ioctl)

proves that it's post_set() that took 155 usecs here, which too does a 
wbinvd().

so it's the invalidation of the cache that takes so long.

i believe that the invalidations are excessive. It is quite likely that
no invalidation has to be done at all. Does your box still start up X
fine if you uncomment all those wbinvd() calls?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Thomas Charbonnel]

Ingo Molnar wrote :
> * Thomas Charbonnel <thomas@undata.org> wrote:
> 
> > As you can see ~1ms was probably an accident, and the latency does not
> > always come from do_timer. The constant is do_IRQ interrupting the
> > idle thread.
> 
> (do you have any sort of powersaving mode (ACPI/APM) enabled? If yes,
> could you try to tune it down as much as possible - disable any
> powersaving option in the BIOS and in the .config - kill apmd, etc.)
> 
> but i dont think it's powersaving - why would such an overhead show up
> in those functions. The only common thing seems to be that both
> mark_offset_tsc() and mask_and_ack_8259A() does port IO, which is slow -
> but still it shouldnt take ~0.5 msecs!
> 
> 	Ingo

Indeed, I just checked and my xrun every ~8 seconds problem is back. I
have acpi compiled in but acpi=off, but it doesn't seem to be honoured
(it was with 2.6.8.1, IIRC).

Thomas

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 15:37, Ingo Molnar wrote:
> i believe that the invalidations are excessive. It is quite likely that
> no invalidation has to be done at all. Does your box still start up X
> fine if you uncomment all those wbinvd() calls?
> 

Commented out all calls to wbinvd(), seems to work fine.  I even tried
repeatedly killing the X server before it could finish starting, no
problems at all.

I guess the worst that could happen here would be display corruption,
which would get fixed on the next refresh?

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> Commented out all calls to wbinvd(), seems to work fine.  I even tried
> repeatedly killing the X server before it could finish starting, no
> problems at all.
> 
> I guess the worst that could happen here would be display corruption,
> which would get fixed on the next refresh?

it's more complex than that - MTRR's are caching attributes that the CPU
listens to. Mis-setting them can cause anything from memory corruption
to hard lockups. The question is, does any of the Intel (or AMD) docs
say that the CPU cache has to be write-back flushed when setting MTRRs,
or were those calls only done out of paranoia?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> it's more complex than that - MTRR's are caching attributes that the
> CPU listens to. Mis-setting them can cause anything from memory
> corruption to hard lockups. The question is, does any of the Intel (or
> AMD) docs say that the CPU cache has to be write-back flushed when
> setting MTRRs, or were those calls only done out of paranoia?

the Intel docs suggest a cache-flush when changing MTRR's, so i guess
we've got to live with this. _Perhaps_ we could move the cache-disabling
and the wbinvd() out of the spinlocked section, but this would make it
preemptable, possibly causing other tasks to run with the CPU cache
disabled! I'd say that is worse than a single 0.5 msec latency during
MTRR setting.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 16:09, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > it's more complex than that - MTRR's are caching attributes that the
> > CPU listens to. Mis-setting them can cause anything from memory
> > corruption to hard lockups. The question is, does any of the Intel (or
> > AMD) docs say that the CPU cache has to be write-back flushed when
> > setting MTRRs, or were those calls only done out of paranoia?
> 
> the Intel docs suggest a cache-flush when changing MTRR's, so i guess
> we've got to live with this. _Perhaps_ we could move the cache-disabling
> and the wbinvd() out of the spinlocked section, but this would make it
> preemptable, possibly causing other tasks to run with the CPU cache
> disabled! I'd say that is worse than a single 0.5 msec latency during
> MTRR setting.
> 

File under boot-time stuff, I guess.  This could be bad if X crashes,
but I can't remember the last time this happened to me, and I use xorg
CVS.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> File under boot-time stuff, I guess.  This could be bad if X crashes,
> but I can't remember the last time this happened to me, and I use xorg
> CVS.

but the first wbinvd() within prepare_set() seems completely unnecessary
- we can flush the cache after disabling the cache just fine.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > File under boot-time stuff, I guess.  This could be bad if X crashes,
> > but I can't remember the last time this happened to me, and I use xorg
> > CVS.
> 
> but the first wbinvd() within prepare_set() seems completely unnecessary
> - we can flush the cache after disabling the cache just fine.

the third wbinvd() in post_set() seems unnecessary too - what kind of
cache do we expect to flush, we've disabled caching in the CPU ... But
the Intel pseudocode does it too - this is a thinko i think.

another thing is that interrupts are not disabled (although the Intel
docs suggest so). It is best to disable interrupts because any handler
executing in this window will perform extremely slowly (because caches
are disabled), and might even interfere with MTRR setting. Best disable
IRQs.

so ... could you try the patch below - does it work and how does the
latency look like now? (ontop of an unmodified generic.c)

	Ingo

--- linux/arch/i386/kernel/cpu/mtrr/generic.c.orig	
+++ linux/arch/i386/kernel/cpu/mtrr/generic.c	
@@ -240,11 +240,14 @@ static void prepare_set(void)
 	/*  Note that this is not ideal, since the cache is only flushed/disabled
 	   for this CPU while the MTRRs are changed, but changing this requires
 	   more invasive changes to the way the kernel boots  */
-	spin_lock(&set_atomicity_lock);
+	/*
+	 * Since we are disabling the cache dont allow any interrupts - they
+	 * would run extremely slow and would only increase the pain:
+	 */
+	spin_lock_irq(&set_atomicity_lock);
 
 	/*  Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
 	cr0 = read_cr0() | 0x40000000;	/* set CD flag */
-	wbinvd();
 	write_cr0(cr0);
 	wbinvd();
 
@@ -266,8 +269,7 @@ static void prepare_set(void)
 
 static void post_set(void)
 {
-	/*  Flush caches and TLBs  */
-	wbinvd();
+	/*  Flush TLBs (no need to flush caches - they are disabled)  */
 	__flush_tlb();
 
 	/* Intel (P6) standard MTRRs */
@@ -279,7 +281,7 @@ static void post_set(void)
 	/*  Restore value of CR4  */
 	if ( cpu_has_pge )
 		write_cr4(cr4);
-	spin_unlock(&set_atomicity_lock);
+	spin_unlock_irq(&set_atomicity_lock);
 }
 
 static void generic_set_all(void)

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 16:20, Ingo Molnar wrote:
> so ... could you try the patch below - does it work and how does the
> latency look like now? (ontop of an unmodified generic.c)
> 

Now it looks like this:

preemption latency trace v1.0.2
-------------------------------
 latency: 574 us, entries: 19 (19)
    -----------------
    | task: X/1391, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: cond_resched+0xd/0x40
 => ended at:   sys_ioctl+0xdf/0x290
=======>
00000001 0.000ms (+0.000ms): touch_preempt_timing (cond_resched)
00000001 0.000ms (+0.000ms): do_blank_screen (vt_ioctl)
00000001 0.000ms (+0.000ms): is_console_locked (do_blank_screen)
00000001 0.001ms (+0.000ms): hide_cursor (do_blank_screen)
00000001 0.002ms (+0.000ms): vgacon_cursor (hide_cursor)
00000001 0.004ms (+0.001ms): hide_softcursor (do_blank_screen)
00000001 0.004ms (+0.000ms): is_console_locked (do_blank_screen)
00000001 0.004ms (+0.000ms): vgacon_save_screen (do_blank_screen)
00000001 0.005ms (+0.000ms): _mmx_memcpy (vgacon_save_screen)
00000001 0.006ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)
00000001 0.481ms (+0.475ms): vgacon_blank (do_blank_screen)
00000001 0.481ms (+0.000ms): vgacon_set_origin (vgacon_blank)
00000001 0.573ms (+0.091ms): set_origin (vt_ioctl)
00000001 0.573ms (+0.000ms): is_console_locked (set_origin)
00000001 0.573ms (+0.000ms): vgacon_set_origin (set_origin)
00000001 0.574ms (+0.000ms): release_console_sem (vt_ioctl)
00000001 0.575ms (+0.000ms): sub_preempt_count (sys_ioctl)
00000001 0.575ms (+0.000ms): _mmx_memcpy (check_preempt_timing)
00000001 0.575ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Tue, 2004-08-31 at 16:20, Ingo Molnar wrote:
> > so ... could you try the patch below - does it work and how does the
> > latency look like now? (ontop of an unmodified generic.c)
> > 
> 
> Now it looks like this:
> 
> preemption latency trace v1.0.2
> -------------------------------
>  latency: 574 us, entries: 19 (19)
>     -----------------
>     | task: X/1391, uid:0 nice:0 policy:0 rt_prio:0
>     -----------------
>  => started at: cond_resched+0xd/0x40
>  => ended at:   sys_ioctl+0xdf/0x290
> =======>
> 00000001 0.000ms (+0.000ms): touch_preempt_timing (cond_resched)
> 00000001 0.000ms (+0.000ms): do_blank_screen (vt_ioctl)
> 00000001 0.000ms (+0.000ms): is_console_locked (do_blank_screen)
> 00000001 0.001ms (+0.000ms): hide_cursor (do_blank_screen)
> 00000001 0.002ms (+0.000ms): vgacon_cursor (hide_cursor)
> 00000001 0.004ms (+0.001ms): hide_softcursor (do_blank_screen)
> 00000001 0.004ms (+0.000ms): is_console_locked (do_blank_screen)
> 00000001 0.004ms (+0.000ms): vgacon_save_screen (do_blank_screen)
> 00000001 0.005ms (+0.000ms): _mmx_memcpy (vgacon_save_screen)
> 00000001 0.006ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)
> 00000001 0.481ms (+0.475ms): vgacon_blank (do_blank_screen)
> 00000001 0.481ms (+0.000ms): vgacon_set_origin (vgacon_blank)
> 00000001 0.573ms (+0.091ms): set_origin (vt_ioctl)
> 00000001 0.573ms (+0.000ms): is_console_locked (set_origin)
> 00000001 0.573ms (+0.000ms): vgacon_set_origin (set_origin)
> 00000001 0.574ms (+0.000ms): release_console_sem (vt_ioctl)
> 00000001 0.575ms (+0.000ms): sub_preempt_count (sys_ioctl)
> 00000001 0.575ms (+0.000ms): _mmx_memcpy (check_preempt_timing)
> 00000001 0.575ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)

hm, this doesnt seem to be an mtrr latency - this is a text-console 
blanking operation apparently running with the BKL enabled.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 16:39, Ingo Molnar wrote:

> hm, this doesnt seem to be an mtrr latency - this is a text-console 
> blanking operation apparently running with the BKL enabled.
> 

Yes, this seemed strange to me too, but I reproduced this several times,
even across reboots.  This one must have been happening right before the
MTRR initialization, and was getting masked by it.

Lee 

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 02:53, Ingo Molnar wrote:
> > > 
> > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5
>
> ok. It seems the random driver is _mostly_ in shape latency-wise, except
> the IP rekeying visible in the above trace. To solve this problem, could
> you try the patch below, ontop of -Q5? It moves the random seed
> generation outside of the spinlock - AFAICS the spinlock is only needed
> to protect the IP sequence counter itself.

This solves the problem with the random driver.  The worst latencies I
am seeing are in netif_receive_skb().  With netdev_max_backlog set to 8,
the worst is about 160 usecs:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace2.txt
http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace3.txt

Setting netdev_max_backlog to 1 has no effect:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace4.txt

I would expect this one to scale with CPU speed, so this is pretty good
considering my relatively underpowered system.  I would imagine on a
fast UP system you would not see any latencies worse than 100 usecs.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Mon, 2004-08-30 at 05:06, Ingo Molnar wrote:
> i've uploaded -Q5 to:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5

This is with netdev_max_backlog = 1:

preemption latency trace v1.0.2
-------------------------------
 latency: 386 us, entries: 328 (328)
    -----------------
    | task: ksoftirqd/0/2, uid:0 nice:-10 policy:0 rt_prio:0
    -----------------
 => started at: tcp_delack_timer+0x1c/0x1d0
 => ended at:   tcp_delack_timer+0x127/0x1d0
=======>
00000001 0.000ms (+0.000ms): tcp_delack_timer (run_timer_softirq)
00000001 0.000ms (+0.000ms): __sk_stream_mem_reclaim (tcp_delack_timer)
00000001 0.004ms (+0.003ms): tcp_v4_do_rcv (tcp_delack_timer)
00000001 0.005ms (+0.001ms): tcp_rcv_established (tcp_v4_do_rcv)
00000001 0.007ms (+0.001ms): __tcp_checksum_complete_user (tcp_rcv_established)
00000001 0.008ms (+0.000ms): skb_checksum (__tcp_checksum_complete_user)
00000001 0.018ms (+0.010ms): tcp_ack (tcp_rcv_established)
00000001 0.019ms (+0.001ms): tcp_ack_update_window (tcp_ack)
00000001 0.021ms (+0.001ms): tcp_urg (tcp_rcv_established)
00000001 0.021ms (+0.000ms): tcp_data_queue (tcp_rcv_established)
00000001 0.023ms (+0.001ms): sk_stream_mem_schedule (tcp_data_queue)

...

00000103 0.377ms (+0.000ms): skb_release_data (kfree_skbmem)
00000103 0.378ms (+0.000ms): kfree (kfree_skbmem)
00000103 0.379ms (+0.000ms): kmem_cache_free (kfree_skbmem)
00000103 0.383ms (+0.004ms): qdisc_restart (dev_queue_xmit)
00000103 0.384ms (+0.000ms): pfifo_fast_dequeue (qdisc_restart)
00000102 0.384ms (+0.000ms): local_bh_enable (dev_queue_xmit)
00000001 0.386ms (+0.001ms): sub_preempt_count (tcp_delack_timer)
00000001 0.387ms (+0.000ms): _mmx_memcpy (check_preempt_timing)
00000001 0.387ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)

Also, I do not get the packet loss/timeout problems that another poster
reported when setting this to 1.  The network works normally, it just
does not affect the latency at all.

Full trace:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace5.txt

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Mon, 2004-08-30 at 05:06, Ingo Molnar wrote:
> i've uploaded -Q5 to:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5

Hmm, 385 usec latency triggered by 'lsof /smb' (this is a samba export):

preemption latency trace v1.0.2
-------------------------------
 latency: 385 us, entries: 626 (626)
    -----------------
    | task: lsof/17876, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: unix_seq_start+0x10/0x50
 => ended at:   unix_seq_stop+0xf/0x30
=======>
00000001 0.000ms (+0.000ms): unix_seq_start (seq_read)
00000001 0.000ms (+0.000ms): unix_seq_idx (unix_seq_start)
00000001 0.027ms (+0.027ms): unix_seq_show (seq_read)
00000002 0.028ms (+0.000ms): sock_i_ino (unix_seq_show)
00000002 0.029ms (+0.001ms): seq_printf (unix_seq_show)
00000002 0.030ms (+0.000ms): vsnprintf (seq_printf)
00000002 0.032ms (+0.002ms): number (vsnprintf)
00000002 0.036ms (+0.004ms): skip_atoi (vsnprintf)
00000002 0.037ms (+0.000ms): number (vsnprintf)
00000002 0.038ms (+0.001ms): skip_atoi (vsnprintf)
00000002 0.039ms (+0.000ms): number (vsnprintf)
00000002 0.039ms (+0.000ms): skip_atoi (vsnprintf)
00000002 0.040ms (+0.000ms): number (vsnprintf)
00000002 0.041ms (+0.000ms): skip_atoi (vsnprintf)
00000002 0.041ms (+0.000ms): number (vsnprintf)
00000002 0.042ms (+0.000ms): skip_atoi (vsnprintf)
00000002 0.043ms (+0.000ms): number (vsnprintf)
00000002 0.043ms (+0.000ms): skip_atoi (vsnprintf)
00000002 0.044ms (+0.000ms): number (vsnprintf)
00000002 0.046ms (+0.001ms): seq_putc (unix_seq_show)
00000002 0.047ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.047ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.047ms (+0.000ms): seq_putc (unix_seq_show)

...

00000002 0.374ms (+0.000ms): number (vsnprintf)
00000002 0.375ms (+0.000ms): skip_atoi (vsnprintf)
00000002 0.376ms (+0.000ms): number (vsnprintf)
00000002 0.377ms (+0.001ms): seq_putc (unix_seq_show)
00000002 0.377ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.378ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.378ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.378ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.379ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.379ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.380ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.380ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.380ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.381ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.381ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.381ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.382ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.382ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.382ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.383ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.383ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.383ms (+0.000ms): seq_putc (unix_seq_show)
00000002 0.384ms (+0.000ms): seq_putc (unix_seq_show)
00000001 0.384ms (+0.000ms): preempt_schedule (unix_seq_show)
00000001 0.384ms (+0.000ms): seq_putc (unix_seq_show)
00000001 0.385ms (+0.000ms): unix_seq_stop (seq_read)
00000001 0.386ms (+0.000ms): sub_preempt_count (unix_seq_stop)
00000001 0.386ms (+0.000ms): _mmx_memcpy (check_preempt_timing)
00000001 0.387ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)

Full trace:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace9.txt

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Mon, 2004-08-30 at 05:06, Ingo Molnar wrote:

>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5

Also, the rt_garbage_collect latency is still present:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace11.txt

Lee

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q6

[Ingo Molnar]

i've released the -Q6 patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q6

ontop of:

  http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

this patch includes two changes that should shorten the networking
latencies reported. There's a new 'RX granularity' sysctl now:

    /proc/sys/net/core/netdev_backlog_granularity

It defaults to the most finegrained value, 1.

netdev_max_backlog has been moved back to the upstream value of 300.

Also, the backlog processing is now sensitive to preemption requests and
will break out early in that case.

(This should not result in TCP connection quality issues (all processing
is restarted after such a breakout), but nevertheless i'd suggest
everyone to keep an eye on lost packets and seemingly hung TCP
connections.)

other changes since -Q5:

 - mtrr simplifications and IRQ-disabling. (reported & tested by Lee
   Revell) Still under discussion though.

 - fix /dev/random driver latency (reported & tested by Lee Revell)

 - move vgacon_do_font_op out of the BKL (reported by P.O. Gaillard)

 - increase percpu space for tracing (by Mark H Johnson)

 - added user-triggerable generic kernel tracing enabled via
   tracing_enabled=2 and turned on via gettimeofday(0,1) and turned off
   via gettimeofday(0,0).

	Ingo

[patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[Ingo Molnar]

i've released the -Q7 patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q7

ontop of:

  http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2

the main change in this patch are more SMP latency fixes. The stock
kernel, even with CONFIG_PREEMPT enabled, didnt have any spin-nicely
preemption logic for the following, commonly used SMP locking
primitives: read_lock(), spin_lock_irqsave(), spin_lock_irq(),
spin_lock_bh(), read_lock_irqsave(), read_lock_irq(), read_lock_bh(),
write_lock_irqsave(), write_lock_irq(), write_lock_bh(). Only
spin_lock() and write_lock() [the two simplest cases] where covered.

In addition to the preemption latency problems, the _irq() variants in
the above list didnt do any IRQ-enabling while spinning - possibly
resulting in excessive irqs-off sections of code!

-Q7 fixes all of these latency problems: we now re-enable interrupts
while spinning in all possible cases, and a spinning op stays
preemptible if this is a beginning of a new critical section.

there's also an SMP related tracing improvement in -Q7: the NMI tracing
code now traces the other CPUs too - this way if an NMI hits a
particulary long section, we'll have a chance to see what the other CPU
was doing. These show up as double do_nmi() trace entries on a 2-CPU x86
box. The first one is the current CPU, subsequent entries are the other
CPUs in the system.

(-Q7 is not that interesting to uniprocessor kernel users, but it would
still be useful to test it, just to see nothing broke (on the
compilation side), lots of spinlock code had to be changed.)

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Martin Josefsson]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

On Wed, 2004-09-01 at 01:03, Lee Revell wrote:

Hi Lee

> This solves the problem with the random driver.  The worst latencies I
> am seeing are in netif_receive_skb().  With netdev_max_backlog set to 8,
> the worst is about 160 usecs:

I'm a bit curious... have you tried these tests with ip_conntrack
enabled?

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[Thomas Charbonnel]

Ingo Molnar wrote :
> i've released the -Q7 patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q7

With Q7 I still get rx latency issues (> 130 us non-preemptible section
from rtl8139_poll). Moreover network connections were extremely slow
(almost hung) until I set /proc/sys/net/core/netdev_backlog_granularity
to 2.

Thomas

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[K.R. Foley]

Thomas Charbonnel wrote:
> Ingo Molnar wrote :
> 
>>i've released the -Q7 patch:
>>
>>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q7
> 
> 
> With Q7 I still get rx latency issues (> 130 us non-preemptible section
> from rtl8139_poll). Moreover network connections were extremely slow
> (almost hung) until I set /proc/sys/net/core/netdev_backlog_granularity
> to 2.
> 
> Thomas
> 
> 
> 
I too am still getting these latencies, although not as often (maybe?). 
I on the other hand am having no problems with slow connections. 
However, this is with very little load on the system. Here is one such 
trace:

http://www.cybsft.com/testresults/2.6.9-rc1-bk4-Q7/latencytrace4.txt

I do have a couple of new traces that seem to be related to transmitting 
data, I think. They are here:

http://www.cybsft.com/testresults/2.6.9-rc1-bk4-Q7/latencytrace2.txt

http://www.cybsft.com/testresults/2.6.9-rc1-bk4-Q7/latencytrace3.txt

kr

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[Peter Zijlstra]

On Wed, 2004-09-01 at 19:09 +0200, Thomas Charbonnel wrote:
> Ingo Molnar wrote :
> > i've released the -Q7 patch:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q7
> 
> With Q7 I still get rx latency issues (> 130 us non-preemptible section
> from rtl8139_poll). Moreover network connections were extremely slow
> (almost hung) until I set /proc/sys/net/core/netdev_backlog_granularity
> to 2.
> 
> Thomas
> 

Me too!
I too have a rtl8139 network card.

kr, what kind of nic do you have since this does not occur on your
machine?

-- 
Peter Zijlstra <a.p.zijlstra@chello.nl>

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[Lee Revell]

On Wed, 2004-09-01 at 16:11, Peter Zijlstra wrote:
> On Wed, 2004-09-01 at 19:09 +0200, Thomas Charbonnel wrote:
> > Ingo Molnar wrote :
> > > i've released the -Q7 patch:
> > > 
> > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q7
> > 
> > With Q7 I still get rx latency issues (> 130 us non-preemptible section
> > from rtl8139_poll). Moreover network connections were extremely slow
> > (almost hung) until I set /proc/sys/net/core/netdev_backlog_granularity
> > to 2.
> > 
> > Thomas
> > 
> 
> Me too!
> I too have a rtl8139 network card.
> 
> kr, what kind of nic do you have since this does not occur on your
> machine?

Hmm, I am not a network driver expert, and this is just a guess, but if
they work anything like sound cards, I would say that that that hardware
will only generate an interrupt when there are 2 packets in its queue.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[K.R. Foley]

Peter Zijlstra wrote:
> On Wed, 2004-09-01 at 19:09 +0200, Thomas Charbonnel wrote:
> 
>>Ingo Molnar wrote :
>>
>>>i've released the -Q7 patch:
>>>
>>>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q7
>>
>>With Q7 I still get rx latency issues (> 130 us non-preemptible section
>>from rtl8139_poll). Moreover network connections were extremely slow
>>(almost hung) until I set /proc/sys/net/core/netdev_backlog_granularity
>>to 2.
>>
>>Thomas
>>
> 
> 
> Me too!
> I too have a rtl8139 network card.
> 
> kr, what kind of nic do you have since this does not occur on your
> machine?
> 

Ethernet Pro 100.

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Wed, 2004-09-01 at 11:52, Martin Josefsson wrote:
> On Wed, 2004-09-01 at 01:03, Lee Revell wrote:
> 
> Hi Lee
> 
> > This solves the problem with the random driver.  The worst latencies I
> > am seeing are in netif_receive_skb().  With netdev_max_backlog set to 8,
> > the worst is about 160 usecs:
> 
> I'm a bit curious... have you tried these tests with ip_conntrack
> enabled?

No, this is disabled in my config.  I will try enabling it.

What would the expected result be?

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Wed, 2004-09-01 at 11:52, Martin Josefsson wrote:
> On Wed, 2004-09-01 at 01:03, Lee Revell wrote:
> 
> Hi Lee
> 
> > This solves the problem with the random driver.  The worst latencies I
> > am seeing are in netif_receive_skb().  With netdev_max_backlog set to 8,
> > the worst is about 160 usecs:
> 
> I'm a bit curious... have you tried these tests with ip_conntrack
> enabled?

OK, loaded the ip_conntrack module.  'cat /proc/net/ip_conntrack'
produced a 2906 usec latency!

preemption latency trace v1.0.2
-------------------------------
 latency: 2906 us, entries: 4000 (7910)
    -----------------
    | task: cat/2091, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: cond_resched+0xd/0x40
 => ended at:   local_bh_enable+0x12/0xa0
=======>
00000101 0.000ms (+0.000ms): touch_preempt_timing (cond_resched)
00000101 0.001ms (+0.001ms): ct_seq_show (seq_read)
00000101 0.002ms (+0.001ms): ct_seq_next (seq_read)
00000101 0.002ms (+0.000ms): ct_seq_show (seq_read)
00000101 0.002ms (+0.000ms): ct_seq_next (seq_read)
00000101 0.003ms (+0.000ms): ct_seq_show (seq_read)
00000101 0.003ms (+0.000ms): ct_seq_next (seq_read)
00000101 0.004ms (+0.000ms): ct_seq_show (seq_read)
00000101 0.004ms (+0.000ms): ct_seq_next (seq_read)
00000101 0.004ms (+0.000ms): ct_seq_show (seq_read)

[ this repeats hundreds of times ]

Full trace:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q6#/var/www/2.6.9-rc1-Q6/trace1.txt

netif_receive_skb still produces ~150 usec latencies with ip_conntrack,
but the code path is different: 

preemption latency trace v1.0.2
-------------------------------
 latency: 145 us, entries: 145 (145)
    -----------------
    | task: ksoftirqd/0/2, uid:0 nice:-10 policy:0 rt_prio:0
    -----------------
 => started at: netif_receive_skb+0x6a/0x1d0
 => ended at:   netif_receive_skb+0x153/0x1d0
=======>
00000001 0.000ms (+0.000ms): netif_receive_skb (process_backlog)
00000001 0.001ms (+0.001ms): packet_rcv_spkt (netif_receive_skb)
00000001 0.002ms (+0.000ms): skb_clone (packet_rcv_spkt)
00000001 0.003ms (+0.000ms): kmem_cache_alloc (skb_clone)
00000001 0.004ms (+0.001ms): memcpy (skb_clone)
00000001 0.006ms (+0.002ms): strlcpy (packet_rcv_spkt)
00000002 0.008ms (+0.001ms): sk_run_filter (packet_rcv_spkt)
00000001 0.011ms (+0.002ms): __kfree_skb (packet_rcv_spkt)
00000001 0.012ms (+0.000ms): kfree_skbmem (__kfree_skb)
00000001 0.012ms (+0.000ms): skb_release_data (kfree_skbmem)
00000001 0.012ms (+0.000ms): kmem_cache_free (kfree_skbmem)
00000001 0.013ms (+0.000ms): ip_rcv (netif_receive_skb)
00000001 0.015ms (+0.001ms): nf_hook_slow (ip_rcv)
00000002 0.016ms (+0.000ms): nf_iterate (nf_hook_slow)
00000002 0.017ms (+0.001ms): ip_conntrack_defrag (nf_iterate)
00000002 0.018ms (+0.000ms): ip_conntrack_in (nf_iterate)
00000002 0.018ms (+0.000ms): ip_ct_find_proto (ip_conntrack_in)
00000103 0.019ms (+0.000ms): __ip_ct_find_proto (ip_ct_find_proto)
00000102 0.019ms (+0.000ms): local_bh_enable (ip_ct_find_proto)
00000002 0.021ms (+0.001ms): tcp_error (ip_conntrack_in)
00000002 0.022ms (+0.001ms): skb_checksum (tcp_error)
00000002 0.031ms (+0.008ms): ip_ct_get_tuple (ip_conntrack_in)
00000002 0.031ms (+0.000ms): tcp_pkt_to_tuple (ip_ct_get_tuple)
00000002 0.032ms (+0.000ms): ip_conntrack_find_get (ip_conntrack_in)
00000103 0.033ms (+0.000ms): __ip_conntrack_find (ip_conntrack_find_get)
00000103 0.033ms (+0.000ms): hash_conntrack (__ip_conntrack_find)
00000102 0.035ms (+0.002ms): local_bh_enable (ip_conntrack_find_get)
00000002 0.036ms (+0.000ms): tcp_packet (ip_conntrack_in)
00000103 0.037ms (+0.000ms): get_conntrack_index (tcp_packet)
00000103 0.038ms (+0.001ms): tcp_in_window (tcp_packet)
00000103 0.039ms (+0.000ms): tcp_sack (tcp_in_window)
00000102 0.041ms (+0.002ms): local_bh_enable (tcp_packet)
00000002 0.042ms (+0.000ms): ip_ct_refresh_acct (tcp_packet)
00000103 0.043ms (+0.000ms): del_timer (ip_ct_refresh_acct)
00000103 0.044ms (+0.000ms): __mod_timer (ip_ct_refresh_acct)
00000105 0.045ms (+0.001ms): internal_add_timer (__mod_timer)
00000102 0.046ms (+0.001ms): local_bh_enable (tcp_packet)
00000002 0.047ms (+0.001ms): ip_rcv_finish (nf_hook_slow)
00000002 0.048ms (+0.000ms): ip_route_input (ip_rcv_finish)
00000002 0.048ms (+0.000ms): rt_hash_code (ip_route_input)
00000002 0.051ms (+0.003ms): ip_local_deliver (ip_rcv_finish)
00000002 0.052ms (+0.000ms): nf_hook_slow (ip_local_deliver)
00000003 0.052ms (+0.000ms): nf_iterate (nf_hook_slow)
00000003 0.053ms (+0.000ms): ip_confirm (nf_iterate)
00000003 0.054ms (+0.000ms): ip_local_deliver_finish (nf_hook_slow)
00000004 0.055ms (+0.001ms): tcp_v4_rcv (ip_local_deliver_finish)
00000004 0.056ms (+0.000ms): tcp_v4_checksum_init (tcp_v4_rcv)
00000005 0.060ms (+0.004ms): tcp_v4_do_rcv (tcp_v4_rcv)
00000005 0.061ms (+0.000ms): tcp_rcv_established (tcp_v4_do_rcv)
00000005 0.062ms (+0.001ms): __tcp_checksum_complete_user (tcp_rcv_established)
00000005 0.063ms (+0.000ms): skb_checksum (__tcp_checksum_complete_user)
00000005 0.065ms (+0.001ms): tcp_rcv_rtt_update (tcp_rcv_established)
00000005 0.066ms (+0.001ms): tcp_event_data_recv (tcp_rcv_established)
00000005 0.069ms (+0.002ms): __tcp_ack_snd_check (tcp_rcv_established)
00000005 0.070ms (+0.000ms): __tcp_select_window (__tcp_ack_snd_check)
00000005 0.070ms (+0.000ms): tcp_send_ack (tcp_rcv_established)
00000005 0.071ms (+0.000ms): alloc_skb (tcp_send_ack)
00000005 0.071ms (+0.000ms): kmem_cache_alloc (alloc_skb)
00000005 0.072ms (+0.000ms): __kmalloc (alloc_skb)
00000005 0.074ms (+0.002ms): tcp_transmit_skb (tcp_send_ack)
00000005 0.076ms (+0.001ms): __tcp_select_window (tcp_transmit_skb)
00000005 0.078ms (+0.001ms): tcp_v4_send_check (tcp_transmit_skb)
00000005 0.079ms (+0.001ms): ip_queue_xmit (tcp_transmit_skb)
00000005 0.082ms (+0.003ms): nf_hook_slow (ip_queue_xmit)
00000006 0.083ms (+0.000ms): nf_iterate (nf_hook_slow)
00000006 0.084ms (+0.000ms): ip_conntrack_defrag (nf_iterate)
00000006 0.084ms (+0.000ms): ip_conntrack_local (nf_iterate)
00000006 0.085ms (+0.000ms): ip_conntrack_in (nf_iterate)
00000006 0.085ms (+0.000ms): ip_ct_find_proto (ip_conntrack_in)
00000107 0.086ms (+0.000ms): __ip_ct_find_proto (ip_ct_find_proto)
00000106 0.086ms (+0.000ms): local_bh_enable (ip_ct_find_proto)
00000006 0.087ms (+0.000ms): tcp_error (ip_conntrack_in)
00000006 0.088ms (+0.000ms): ip_ct_get_tuple (ip_conntrack_in)
00000006 0.088ms (+0.000ms): tcp_pkt_to_tuple (ip_ct_get_tuple)
00000006 0.089ms (+0.000ms): ip_conntrack_find_get (ip_conntrack_in)
00000107 0.089ms (+0.000ms): __ip_conntrack_find (ip_conntrack_find_get)
00000107 0.089ms (+0.000ms): hash_conntrack (__ip_conntrack_find)
00000106 0.090ms (+0.000ms): local_bh_enable (ip_conntrack_find_get)
00000006 0.091ms (+0.000ms): tcp_packet (ip_conntrack_in)
00000107 0.091ms (+0.000ms): get_conntrack_index (tcp_packet)
00000107 0.092ms (+0.000ms): tcp_in_window (tcp_packet)
00000107 0.093ms (+0.000ms): tcp_sack (tcp_in_window)
00000106 0.094ms (+0.001ms): local_bh_enable (tcp_packet)
00000006 0.094ms (+0.000ms): ip_ct_refresh_acct (tcp_packet)
00000107 0.095ms (+0.000ms): del_timer (ip_ct_refresh_acct)
00000107 0.095ms (+0.000ms): __mod_timer (ip_ct_refresh_acct)
00000109 0.096ms (+0.000ms): internal_add_timer (__mod_timer)
00000106 0.097ms (+0.000ms): local_bh_enable (tcp_packet)
00000006 0.098ms (+0.000ms): dst_output (nf_hook_slow)
00000006 0.098ms (+0.000ms): ip_output (dst_output)
00000006 0.099ms (+0.000ms): ip_finish_output (dst_output)
00000006 0.099ms (+0.000ms): nf_hook_slow (ip_finish_output)
00000007 0.100ms (+0.000ms): nf_iterate (nf_hook_slow)
00000007 0.100ms (+0.000ms): ip_refrag (nf_iterate)
00000007 0.101ms (+0.000ms): ip_confirm (ip_refrag)
00000007 0.101ms (+0.000ms): ip_finish_output2 (nf_hook_slow)
00000107 0.102ms (+0.001ms): local_bh_enable (ip_finish_output2)
00000007 0.103ms (+0.000ms): neigh_resolve_output (ip_finish_output2)
00000108 0.104ms (+0.001ms): eth_header (neigh_resolve_output)
00000107 0.106ms (+0.001ms): local_bh_enable (neigh_resolve_output)
00000007 0.107ms (+0.001ms): dev_queue_xmit (neigh_resolve_output)
00000109 0.108ms (+0.001ms): pfifo_fast_enqueue (dev_queue_xmit)
00000109 0.109ms (+0.000ms): qdisc_restart (dev_queue_xmit)
00000109 0.110ms (+0.000ms): pfifo_fast_dequeue (qdisc_restart)
00000109 0.111ms (+0.001ms): dev_queue_xmit_nit (qdisc_restart)
0000010a 0.112ms (+0.000ms): skb_clone (dev_queue_xmit_nit)
0000010a 0.112ms (+0.000ms): kmem_cache_alloc (skb_clone)
0000010a 0.113ms (+0.000ms): memcpy (skb_clone)
0000010a 0.114ms (+0.001ms): packet_rcv_spkt (dev_queue_xmit_nit)
0000010a 0.114ms (+0.000ms): strlcpy (packet_rcv_spkt)
0000010b 0.115ms (+0.000ms): sk_run_filter (packet_rcv_spkt)
0000010a 0.116ms (+0.000ms): __kfree_skb (packet_rcv_spkt)
0000010a 0.116ms (+0.000ms): kfree_skbmem (__kfree_skb)
0000010a 0.117ms (+0.000ms): skb_release_data (kfree_skbmem)
0000010a 0.117ms (+0.000ms): kmem_cache_free (kfree_skbmem)
00000109 0.118ms (+0.000ms): rhine_start_tx (qdisc_restart)
00000109 0.122ms (+0.004ms): qdisc_restart (dev_queue_xmit)
00000109 0.122ms (+0.000ms): pfifo_fast_dequeue (qdisc_restart)
00000108 0.123ms (+0.000ms): local_bh_enable (dev_queue_xmit)
00000005 0.124ms (+0.001ms): sock_def_readable (tcp_rcv_established)
00000006 0.125ms (+0.000ms): __wake_up (sock_def_readable)
00000007 0.126ms (+0.000ms): __wake_up_common (__wake_up)
00000007 0.127ms (+0.000ms): default_wake_function (__wake_up_common)
00000007 0.127ms (+0.000ms): try_to_wake_up (__wake_up_common)
00000007 0.128ms (+0.000ms): task_rq_lock (try_to_wake_up)
00000008 0.129ms (+0.000ms): activate_task (try_to_wake_up)
00000008 0.129ms (+0.000ms): sched_clock (activate_task)
00000008 0.130ms (+0.000ms): recalc_task_prio (activate_task)
00000008 0.131ms (+0.000ms): effective_prio (recalc_task_prio)
00000008 0.131ms (+0.000ms): enqueue_task (activate_task)
00010007 0.133ms (+0.001ms): do_IRQ (__wake_up)
00010008 0.134ms (+0.000ms): mask_and_ack_8259A (do_IRQ)
00010008 0.138ms (+0.004ms): generic_redirect_hardirq (do_IRQ)
00010008 0.138ms (+0.000ms): wake_up_process (generic_redirect_hardirq)
00010008 0.139ms (+0.000ms): try_to_wake_up (wake_up_process)
00010008 0.139ms (+0.000ms): task_rq_lock (try_to_wake_up)
00010009 0.140ms (+0.000ms): activate_task (try_to_wake_up)
00010009 0.140ms (+0.000ms): sched_clock (activate_task)
00010009 0.140ms (+0.000ms): recalc_task_prio (activate_task)
00010009 0.141ms (+0.000ms): effective_prio (recalc_task_prio)
00010009 0.141ms (+0.000ms): enqueue_task (activate_task)
00000001 0.145ms (+0.003ms): sub_preempt_count (netif_receive_skb)
00000001 0.146ms (+0.000ms): update_max_trace (check_preempt_timing)
00000001 0.146ms (+0.000ms): _mmx_memcpy (update_max_trace)
00000001 0.147ms (+0.000ms): kernel_fpu_begin (_mmx_memcpy)

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[Ingo Molnar]

* K.R. Foley <kr@cybsft.com> wrote:

> This is an interesting one. ~3.9ms generated here by amlat in do_IRQ:

the overhead is not in do_IRQ():

> 00000001 0.000ms (+0.000ms): n_tty_receive_buf (pty_write)
> 00010001 3.992ms (+3.992ms): do_IRQ (n_tty_receive_buf)

the overhead is always relative to the previous entry - so the overhead
was in n_tty_receive_buf() [that is the function that was interrupted by
do_IRQ()]. But it's a bit weird - you should have gotten timer IRQs
every 1 msec. Does n_tty_receive_buf() run with irqs disabled perhaps?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > 00000001 0.000ms (+0.000ms): n_tty_receive_buf (pty_write)
> > 00010001 3.992ms (+3.992ms): do_IRQ (n_tty_receive_buf)
> 
> the overhead is always relative to the previous entry [...]

i've changed the /proc/latency_trace output in my tree to print the
latency of this entry relative to the next entry, not the previous
entry. This should be more intuitive than using the previous entry.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> TSC mcount
> ==========
> 
> >From your patch, added several mcount() calls to mark_offset_tsc.
> To summarize the trace results, here is a table that reports the
> delta times for each location. Each row represents one of the dozen
> trace outputs per latency trace. Row columns are the file names
> (lt.xx) in the tar file. Times are in usec.
> 
>      01  03  04  13  16  26  27  31  32  35  37  39
> 01  000 000 000 069 000 000 000 000 000 081 136 000
> 02  032 000 000 000 000 000 000 000 000 000 000 000
> 03  000 000 000 000 000 000 000 000 000 000 000 000
> 04  001 000 000 070 231 139 138 093 252 062 000 067
> 05  000 000 000 000 000 000 000 000 000 000 000 000
> 06  042 003 003 004 003 004 004 053 145 076 003 004
> 07  004 004 004 004 008 004 005 006 010 011 004 005
> 08  001 001 002 002 008 002 002 002 001 002 001 002
> 09  000 000 000 000 000 000 000 000 000 000 000 000
> 10  000 000 000 000 000 000 000 000 000 000 000 000
> 11  000 000 000 000 000 000 000 000 000 000 000 000
> 12  000 000 000 061 000 130 129 129 000 000 000 060

so ... not all codepaths contribute to the high latency.

it seems the following ones generate the highest overhead: #03-#04,
#05-#06. What code is there between mcount() #03 and #04?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Thu, 2004-09-02 at 12:59, Jaroslav Kysela wrote:
> On Tue, 31 Aug 2004, Ingo Molnar wrote:
> 
> > > > Ugh.  Please remove alsa-devel from any followups, as they seem to have
> > > > inadvertently enabled moderation.
> > > 
> > > IIRC, recently the moderation was disabled, so this should be no
> > > longer problem.
> > 
> > FYI, i still got 'your mail awaits moderation' messages just 2 minutes
> > ago.
> 
> Sorry, still one button was checked wrongly. Now it's definitely 
> corrected.
> 

Can you please approve all the messages that are awaiting moderator
approval now?  I have not received a message from alsa-devel since
Tuesday afternoon.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Jaroslav Kysela]

On Tue, 31 Aug 2004, Ingo Molnar wrote:

> > > Ugh.  Please remove alsa-devel from any followups, as they seem to have
> > > inadvertently enabled moderation.
> > 
> > IIRC, recently the moderation was disabled, so this should be no
> > longer problem.
> 
> FYI, i still got 'your mail awaits moderation' messages just 2 minutes
> ago.

Sorry, still one button was checked wrongly. Now it's definitely 
corrected.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> In 2.4, it appears that the duration of the write system call is
> basically fixed and dependent on the duration of the audio fragment.
> In 2.6, this behavior is now different. If I look at the chart in
> detail, it appears the system is queueing up several write operations
> during the first few seconds of testing. You can see this by
> consistently low elapsed times for the write system call. Then the
> elapsed time for the write bounces up / down in a sawtooth pattern
> over a 1 msec range. Could someone explain the cause of this new
> behavior and if there is a setting to restore the old behavior? I am
> concerned that this queueing adds latency to audio operations (when
> trying to synchronize audio with other real time behavior).

i think i found the reason for the sawtooth: it's a bug in hardirq
redirection. In certain situations we can end up not waking up softirqd,
resulting in a random 0-1msec latency between hardirq arrival and
softirq execution. We dont see higher latencies because timer IRQs
always wake up softirqd which hides the bug to a certain degree.

I'll fix this in -Q8.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Takashi Iwai]

At Wed, 1 Sep 2004 09:37:39 -0500,
Mark_H_Johnson@raytheon.com wrote:
> 
> >Ok, the second try.
> 
> This patch appears to work well. No snd_es1371 traces in over 25 minutes
> of testing (I had a couple hundred yesterday in similar tests). The sound
> was OK as well.

Thanks for confirmation.
I merged it to ALSA tree, hopefully promoted to bk tree soon later.


Takashi

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> >since the latency tracer does not trigger, we need a modified tracer to
> >find out what's happening during such long delays. I've attached the
> >'user-latency-tracer' patch ontop of -Q5, which is a modification of the
> >latency tracer.
> 
> The attached file has a set of user latency traces taken about 1 second
> apart at the start of running "latencytest" (a tracing version of it).
> 
> The first few show the "fast path" result of calling write. The remaining
> ones vary with three different symptoms:
>  - the fast path
>  - a "long" delay (about 1000 traces)

lt.03 shows this long delay. Here are the relevant sections, the delay
seems to be triggered by the ALSA driver, by scheduling away
intentionally, in snd_pcn_lib_write1():

 00000002 0.023ms (+0.001ms): snd_pcm_update_hw_ptr (snd_pcm_lib_write1)
 00000002 0.023ms (+0.000ms): snd_ensoniq_playback1_pointer (snd_pcm_update_hw_ptr)
 00000002 0.025ms (+0.002ms): snd_pcm_playback_silence (snd_pcm_update_hw_ptr)
 00000002 0.026ms (+0.000ms): add_wait_queue (snd_pcm_lib_write1)
 00000000 0.027ms (+0.000ms): schedule_timeout (snd_pcm_lib_write1)
 00000000 0.027ms (+0.000ms): __mod_timer (schedule_timeout)

then it sleeps 700 usecs and is woken up by the soundcard's IRQ via
snd_pcm_period_elapsed():

 00010000 0.771ms (+0.000ms): snd_audiopci_interrupt (generic_handle_IRQ_event)
 00010000 0.774ms (+0.002ms): snd_pcm_period_elapsed (snd_audiopci_interrupt)
 00010002 0.775ms (+0.001ms): snd_ensoniq_playback1_pointer (snd_pcm_period_elapsed)
 00010002 0.779ms (+0.003ms): snd_pcm_playback_silence (snd_pcm_period_elapsed)
 00010002 0.780ms (+0.001ms): __wake_up (snd_pcm_period_elapsed)
 00010003 0.780ms (+0.000ms): __wake_up_common (__wake_up)
 00010003 0.780ms (+0.000ms): default_wake_function (__wake_up_common)
 00010003 0.781ms (+0.000ms): try_to_wake_up (__wake_up_common)
 00010003 0.782ms (+0.000ms): task_rq_lock (try_to_wake_up)
 00010004 0.783ms (+0.001ms): activate_task (try_to_wake_up)

and returns to userspace shortly afterwards. So the question is, why
does snd_pcm_lib_write1() cause the latencytest task to sleep (while
latencytest clearly doesnt expect this to happen and reports this as a
latency) - is this by design?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Mark_H_Johnson]

>... Need to increase that data area so
>#define PERCPU_ENOUGH_ROOM 196608
>or something similar (should leave about 50K free for modules).
>
>I will rebuild with this change plus the latest of the others.

This booted fine today.

I reported the results of the audio patch separately. That seems to have
removed the audio latencies I saw previously.

A Whopper!
==========

A latency trace > 20 msec was seen (once). It starts pretty bad and then
gets stuck in a 1 msec loop.

preemption latency trace v1.0.2
-------------------------------
 latency: 23120 us, entries: 406 (406)
    -----------------
    | task: latencytest/4999, uid:0 nice:0 policy:1 rt_prio:99
    -----------------
 => started at: del_timer+0x4c/0x150
 => ended at:   del_timer+0xf2/0x150
=======>
00000001 0.000ms (+0.000ms): del_timer (del_singleshot_timer_sync)
00000001 0.700ms (+0.700ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 0.700ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 0.701ms (+0.000ms): profile_hook (profile_tick)
00010002 0.701ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 0.702ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 0.702ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 0.702ms (+0.000ms): update_one_process (update_process_times)
00010001 0.703ms (+0.000ms): run_local_timers (update_process_times)
00010001 0.703ms (+0.000ms): raise_softirq (update_process_times)
00010001 0.703ms (+0.000ms): scheduler_tick (update_process_times)
00010001 0.703ms (+0.000ms): sched_clock (scheduler_tick)
00010001 0.704ms (+0.001ms): rebalance_tick (scheduler_tick)
00000002 0.704ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 0.705ms (+0.000ms): __do_softirq (do_softirq)
00000002 0.705ms (+0.000ms): wake_up_process (do_softirq)
00000002 0.705ms (+0.000ms): try_to_wake_up (wake_up_process)
00000002 0.705ms (+0.000ms): task_rq_lock (try_to_wake_up)
00000003 0.706ms (+0.000ms): activate_task (try_to_wake_up)
00000003 0.706ms (+0.000ms): sched_clock (activate_task)
00000003 0.706ms (+0.000ms): recalc_task_prio (activate_task)
00000003 0.706ms (+0.000ms): effective_prio (recalc_task_prio)
00000003 0.706ms (+0.000ms): enqueue_task (activate_task)
00010001 1.301ms (+0.594ms): do_IRQ (.text.lock.timer)
00010002 1.302ms (+0.000ms): mask_and_ack_level_ioapic_irq (do_IRQ)
00010002 1.302ms (+0.000ms): mask_IO_APIC_irq
(mask_and_ack_level_ioapic_irq)
00010003 1.302ms (+0.000ms): __mask_IO_APIC_irq (mask_IO_APIC_irq)
00010003 1.302ms (+0.000ms): __modify_IO_APIC_irq (__mask_IO_APIC_irq)
00010002 1.315ms (+0.013ms): generic_redirect_hardirq (do_IRQ)
00010001 1.315ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010001 1.316ms (+0.000ms): usb_hcd_irq (generic_handle_IRQ_event)
00010001 1.316ms (+0.000ms): uhci_irq (usb_hcd_irq)
00010001 1.316ms (+0.000ms): usb_hcd_irq (generic_handle_IRQ_event)
00010001 1.317ms (+0.000ms): uhci_irq (usb_hcd_irq)
00010001 1.317ms (+0.000ms): snd_audiopci_interrupt
(generic_handle_IRQ_event)
00010001 1.319ms (+0.001ms): snd_pcm_period_elapsed
(snd_audiopci_interrupt)
00010003 1.319ms (+0.000ms): snd_ensoniq_playback1_pointer
(snd_pcm_period_elapsed)
00010003 1.321ms (+0.001ms): snd_pcm_playback_silence
(snd_pcm_period_elapsed)
00010003 1.321ms (+0.000ms): __wake_up (snd_pcm_period_elapsed)
00010004 1.321ms (+0.000ms): __wake_up_common (__wake_up)
00010004 1.322ms (+0.000ms): default_wake_function (__wake_up_common)
00010004 1.322ms (+0.000ms): try_to_wake_up (__wake_up_common)
00010004 1.322ms (+0.000ms): task_rq_lock (try_to_wake_up)
00010001 1.323ms (+0.000ms): kill_fasync (snd_pcm_period_elapsed)
00010002 1.323ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010002 1.323ms (+0.000ms): end_level_ioapic_irq (do_IRQ)
00010002 1.323ms (+0.000ms): unmask_IO_APIC_irq (do_IRQ)
00010003 1.324ms (+0.000ms): __unmask_IO_APIC_irq (unmask_IO_APIC_irq)
00010003 1.324ms (+0.000ms): __modify_IO_APIC_irq (__unmask_IO_APIC_irq)
00000002 1.338ms (+0.013ms): do_softirq (do_IRQ)
00000002 1.338ms (+0.000ms): __do_softirq (do_softirq)
00000001 1.699ms (+0.361ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 1.700ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 1.700ms (+0.000ms): profile_hook (profile_tick)
00010002 1.700ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 1.700ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 1.700ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 1.701ms (+0.000ms): update_one_process (update_process_times)
00010001 1.701ms (+0.000ms): run_local_timers (update_process_times)
00010001 1.701ms (+0.000ms): raise_softirq (update_process_times)
00010001 1.701ms (+0.000ms): scheduler_tick (update_process_times)
00010001 1.701ms (+0.000ms): sched_clock (scheduler_tick)
00010001 1.702ms (+0.000ms): rebalance_tick (scheduler_tick)
00000002 1.702ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 1.702ms (+0.000ms): __do_softirq (do_softirq)
00000001 2.699ms (+0.996ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 2.699ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 2.699ms (+0.000ms): profile_hook (profile_tick)
00010002 2.699ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 2.699ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 2.700ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 2.700ms (+0.000ms): update_one_process (update_process_times)
00010001 2.700ms (+0.000ms): run_local_timers (update_process_times)
00010001 2.700ms (+0.000ms): raise_softirq (update_process_times)
00010001 2.700ms (+0.000ms): scheduler_tick (update_process_times)
00010001 2.701ms (+0.000ms): sched_clock (scheduler_tick)
00010001 2.701ms (+0.000ms): rebalance_tick (scheduler_tick)
00000002 2.701ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 2.701ms (+0.000ms): __do_softirq (do_softirq)
00010001 2.759ms (+0.057ms): do_IRQ (.text.lock.timer)
00010002 2.759ms (+0.000ms): mask_and_ack_level_ioapic_irq (do_IRQ)
00010002 2.759ms (+0.000ms): mask_IO_APIC_irq
(mask_and_ack_level_ioapic_irq)
00010003 2.760ms (+0.000ms): __mask_IO_APIC_irq (mask_IO_APIC_irq)
00010003 2.760ms (+0.000ms): __modify_IO_APIC_irq (__mask_IO_APIC_irq)
00010002 2.773ms (+0.013ms): generic_redirect_hardirq (do_IRQ)
00010001 2.773ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010001 2.773ms (+0.000ms): usb_hcd_irq (generic_handle_IRQ_event)
00010001 2.774ms (+0.000ms): uhci_irq (usb_hcd_irq)
00010001 2.774ms (+0.000ms): usb_hcd_irq (generic_handle_IRQ_event)
00010001 2.774ms (+0.000ms): uhci_irq (usb_hcd_irq)
00010001 2.775ms (+0.000ms): snd_audiopci_interrupt
(generic_handle_IRQ_event)
00010001 2.776ms (+0.001ms): snd_pcm_period_elapsed
(snd_audiopci_interrupt)
00010003 2.777ms (+0.000ms): snd_ensoniq_playback1_pointer
(snd_pcm_period_elapsed)
00010003 2.778ms (+0.001ms): snd_pcm_playback_silence
(snd_pcm_period_elapsed)
00010003 2.779ms (+0.001ms): snd_pcm_format_set_silence
(snd_pcm_playback_silence)
00010003 2.780ms (+0.000ms): snd_pcm_format_set_silence
(snd_pcm_playback_silence)
00010003 2.781ms (+0.000ms): xrun (snd_pcm_period_elapsed)
00010003 2.781ms (+0.000ms): snd_pcm_stop (xrun)
00010003 2.782ms (+0.000ms): snd_pcm_action (snd_pcm_stop)
00010003 2.783ms (+0.000ms): snd_pcm_action_single (snd_pcm_action)
00010003 2.783ms (+0.000ms): snd_pcm_pre_stop (snd_pcm_action_single)
00010003 2.783ms (+0.000ms): snd_pcm_do_stop (snd_pcm_action_single)
00010003 2.784ms (+0.000ms): snd_ensoniq_trigger (snd_pcm_do_stop)
00010003 2.786ms (+0.001ms): snd_pcm_post_stop (snd_pcm_action_single)
00010003 2.786ms (+0.000ms): snd_pcm_trigger_tstamp (snd_pcm_post_stop)
00010003 2.787ms (+0.000ms): do_gettimeofday (snd_pcm_trigger_tstamp)
00010003 2.787ms (+0.000ms): get_offset_tsc (do_gettimeofday)
00010003 2.788ms (+0.000ms): snd_timer_notify (snd_pcm_post_stop)
00010003 2.789ms (+0.001ms): snd_pcm_tick_set (snd_pcm_post_stop)
00010003 2.790ms (+0.000ms): snd_pcm_system_tick_set (snd_pcm_post_stop)
00010003 2.790ms (+0.000ms): del_timer (snd_pcm_post_stop)
00010003 2.791ms (+0.000ms): __wake_up (snd_pcm_action_single)
00010004 2.791ms (+0.000ms): __wake_up_common (__wake_up)
00010004 2.791ms (+0.000ms): default_wake_function (__wake_up_common)
00010004 2.791ms (+0.000ms): try_to_wake_up (__wake_up_common)
00010004 2.791ms (+0.000ms): task_rq_lock (try_to_wake_up)
00010001 2.792ms (+0.000ms): kill_fasync (snd_pcm_period_elapsed)
00010002 2.793ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010002 2.793ms (+0.000ms): end_level_ioapic_irq (do_IRQ)
00010002 2.793ms (+0.000ms): unmask_IO_APIC_irq (do_IRQ)
00010003 2.793ms (+0.000ms): __unmask_IO_APIC_irq (unmask_IO_APIC_irq)
00010003 2.793ms (+0.000ms): __modify_IO_APIC_irq (__unmask_IO_APIC_irq)
00000002 2.807ms (+0.013ms): do_softirq (do_IRQ)
00000002 2.807ms (+0.000ms): __do_softirq (do_softirq)
00000001 3.698ms (+0.890ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 3.698ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 3.698ms (+0.000ms): profile_hook (profile_tick)
00010002 3.699ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 3.699ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 3.699ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 3.699ms (+0.000ms): update_one_process (update_process_times)
00010001 3.700ms (+0.000ms): run_local_timers (update_process_times)
00010001 3.700ms (+0.000ms): raise_softirq (update_process_times)
00010001 3.700ms (+0.000ms): scheduler_tick (update_process_times)
00010001 3.700ms (+0.000ms): sched_clock (scheduler_tick)
00010001 3.701ms (+0.000ms): rebalance_tick (scheduler_tick)
00000002 3.701ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 3.701ms (+0.000ms): __do_softirq (do_softirq)
00000001 4.697ms (+0.996ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 4.698ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 4.698ms (+0.000ms): profile_hook (profile_tick)
00010002 4.698ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 4.698ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 4.698ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 4.699ms (+0.000ms): update_one_process (update_process_times)
00010001 4.699ms (+0.000ms): run_local_timers (update_process_times)
00010001 4.699ms (+0.000ms): raise_softirq (update_process_times)
00010001 4.699ms (+0.000ms): scheduler_tick (update_process_times)
00010001 4.699ms (+0.000ms): sched_clock (scheduler_tick)
00010001 4.700ms (+0.000ms): rebalance_tick (scheduler_tick)
00000002 4.700ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 4.700ms (+0.000ms): __do_softirq (do_softirq)
00000001 5.697ms (+0.996ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 5.697ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 5.697ms (+0.000ms): profile_hook (profile_tick)
00010002 5.697ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 5.698ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 5.698ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 5.698ms (+0.000ms): update_one_process (update_process_times)
00010001 5.698ms (+0.000ms): run_local_timers (update_process_times)
00010001 5.698ms (+0.000ms): raise_softirq (update_process_times)
00010001 5.698ms (+0.000ms): scheduler_tick (update_process_times)
(this cycle repeats several times, exited as follows)
00000001 21.686ms (+0.996ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 21.686ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 21.686ms (+0.000ms): profile_hook (profile_tick)
00010002 21.686ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 21.687ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 21.687ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 21.687ms (+0.000ms): update_one_process (update_process_times)
00010001 21.687ms (+0.000ms): run_local_timers (update_process_times)
00010001 21.687ms (+0.000ms): raise_softirq (update_process_times)
00010001 21.687ms (+0.000ms): scheduler_tick (update_process_times)
00010001 21.688ms (+0.000ms): sched_clock (scheduler_tick)
00010001 21.688ms (+0.000ms): rebalance_tick (scheduler_tick)
00000002 21.688ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 21.688ms (+0.000ms): __do_softirq (do_softirq)
00000001 22.685ms (+0.996ms): smp_apic_timer_interrupt (.text.lock.timer)
00010001 22.685ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 22.685ms (+0.000ms): profile_hook (profile_tick)
00010002 22.686ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 22.686ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 22.686ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 22.686ms (+0.000ms): update_one_process (update_process_times)
00010001 22.686ms (+0.000ms): run_local_timers (update_process_times)
00010001 22.686ms (+0.000ms): raise_softirq (update_process_times)
00010001 22.687ms (+0.000ms): scheduler_tick (update_process_times)
00010001 22.687ms (+0.000ms): sched_clock (scheduler_tick)
00010001 22.687ms (+0.000ms): rebalance_tick (scheduler_tick)
00000002 22.687ms (+0.000ms): do_softirq (smp_apic_timer_interrupt)
00000002 22.688ms (+0.000ms): __do_softirq (do_softirq)
00000001 23.120ms (+0.432ms): sub_preempt_count (del_timer)
00000001 23.121ms (+0.000ms): update_max_trace (check_preempt_timing)

TSC mcount
==========

>From your patch, added several mcount() calls to mark_offset_tsc.
To summarize the trace results, here is a table that reports the
delta times for each location. Each row represents one of the dozen
trace outputs per latency trace. Row columns are the file names
(lt.xx) in the tar file. Times are in usec.

     01  03  04  13  16  26  27  31  32  35  37  39
01  000 000 000 069 000 000 000 000 000 081 136 000
02  032 000 000 000 000 000 000 000 000 000 000 000
03  000 000 000 000 000 000 000 000 000 000 000 000
04  001 000 000 070 231 139 138 093 252 062 000 067
05  000 000 000 000 000 000 000 000 000 000 000 000
06  042 003 003 004 003 004 004 053 145 076 003 004
07  004 004 004 004 008 004 005 006 010 011 004 005
08  001 001 002 002 008 002 002 002 001 002 001 002
09  000 000 000 000 000 000 000 000 000 000 000 000
10  000 000 000 000 000 000 000 000 000 000 000 000
11  000 000 000 000 000 000 000 000 000 000 000 000
12  000 000 000 061 000 130 129 129 000 000 000 060

NOTE: This is not all the results w/ mark_offset_tsc listed. After the
first few items, I only listed those with significant (>100 usec) delays.

Network Poll
============

I still have a few traces w/ long durations during network poll. Since
you merged that other change into Q6 (and I assume Q7) I will try that
later today.

I will also try to make a modified version of latencytest that does
the extended trace of the write system call (occasionally) to see what
is going on there as well.

For reference, I will send the tar file with all the traces in another
message (not to linux-kernel).

 --Mark

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Mark_H_Johnson]

>Ok, the second try.

This patch appears to work well. No snd_es1371 traces in over 25 minutes
of testing (I had a couple hundred yesterday in similar tests). The sound
was OK as well.

I am seeing some additional CPU overhead during the disk I/O tests with
today's kernel but I don't think this is due to this patch.

Thanks.
  --Mark

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]


* Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:

> >regarding this particular latency, could you try the attached patch
> >ontop of -Q5? It turns the ->poll() loop into separate, individually
> >preemptable iterations instead of one batch of processing. In theory
> >this should result in latency being lower regardless of the
> >netdev_max_backlog value.

> In all cases, Ctrl-Alt-Del was good enough to get a clean reboot.
> 
> This looks like a bad patch; will go back to the last good kernel for
> further testing.

ok, i think i found why it broke for you - forgot to update 'budget' in
the else branch. Could you try the attached patch ontop of -Q5? You'll
get a new sysctl as /proc/sys/net/core/netdev_backlog_granularity, with
a default value of 1. This should result in a working system with a
healthy backlog but with the preemption properties of netdev_max_backlog
== 1. Increasing the granularity will do give more chunkyness of
processing. Do you still get long RX latencies with the finest
granularity of 1, without any of the bad side-effects like booting
problems or lost packets?

	Ingo

[-- Attachment #2: rx-granularity.patch --]
[-- Type: text/plain, Size: 1949 bytes --]

--- linux/net/core/dev.c.orig
+++ linux/net/core/dev.c
@@ -1403,6 +1403,7 @@ out:
   =======================================================================*/
 
 int netdev_max_backlog = 8;
+int netdev_backlog_granularity = 1;
 int weight_p = 64;            /* old backlog weight */
 /* These numbers are selected based on intuition and some
  * experimentatiom, if you have more scientific way of doing this
@@ -1903,7 +1904,8 @@ static void net_rx_action(struct softirq
 {
 	struct softnet_data *queue = &__get_cpu_var(softnet_data);
 	unsigned long start_time = jiffies;
-	int budget = netdev_max_backlog;
+	int budget = netdev_max_backlog, left,
+		gran = netdev_backlog_granularity;
 
 	
 	local_irq_disable();
@@ -1926,7 +1928,8 @@ static void net_rx_action(struct softirq
 		dev = list_entry(queue->poll_list.next,
 				 struct net_device, poll_list);
 
-		if (dev->quota <= 0 || dev->poll(dev, &budget)) {
+		left = gran;
+		if (dev->quota <= 0 || dev->poll(dev, &left)) {
 			local_irq_disable();
 			list_del(&dev->poll_list);
 			list_add_tail(&dev->poll_list, &queue->poll_list);
@@ -1938,6 +1941,7 @@ static void net_rx_action(struct softirq
 			dev_put(dev);
 			local_irq_disable();
 		}
+		budget -= gran - left;
 	}
 out:
 	local_irq_enable();
--- linux/net/core/sysctl_net_core.c.orig
+++ linux/net/core/sysctl_net_core.c
@@ -12,7 +12,7 @@
 
 #ifdef CONFIG_SYSCTL
 
-extern int netdev_max_backlog;
+extern int netdev_max_backlog, netdev_backlog_granularity;
 extern int weight_p;
 extern int no_cong_thresh;
 extern int no_cong;
@@ -99,6 +99,14 @@ ctl_table core_table[] = {
 		.proc_handler	= &proc_dointvec
 	},
 	{
+		.ctl_name	= NET_CORE_MAX_BACKLOG,
+		.procname	= "netdev_backlog_granularity",
+		.data		= &netdev_backlog_granularity,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec
+	},
+	{
 		.ctl_name	= NET_CORE_NO_CONG_THRESH,
 		.procname	= "no_cong_thresh",
 		.data		= &no_cong_thresh,

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Andi Kleen <ak@muc.de> wrote:

> > the third wbinvd() in post_set() seems unnecessary too - what kind of
> > cache do we expect to flush, we've disabled caching in the CPU ... But
> > the Intel pseudocode does it too - this is a thinko i think.
> 
> The multiple steps are needed, otherwise there can be problems with
> hyperthreading (the first x86-64 didn't do it in all cases, and it
> causes occassional problens with Intel CPUs)

i'm quite sure the first one is unnecessary - any interrupt could
already come inbetween and generate dirty cachelines, so it has zero
guaranteed effect.

the third one _seems_ unnecessary - what dirty cachelines can there be
after we've disabled the cache?

the hyperthreading question is valid but no way does the flush solve the
HT problems this code already has! The only proper way i can see to
_guarantee_ zero cache effects is to do a 'catch CPUs', 'disable IRQs,
all caches and flush them', and 'set MTRR's on all CPUs', 'enable all
caches', 'continue CPUs' sequence, SMP-synchronized at every point.
Otherwise you can always get some dirty cache state due to HT races and
whatever data corruption there might occur. I believe the MTRR code is
quite incorrectly coded as-is.

> Also repeated calls of this are relatively cheap because at the second
> time there is not much to flush anymore.

the trace shows that the first one is 300 usecs, the second and third 
one is 150 usecs each, so it's not exactly cheap.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Andi Kleen]

Ingo Molnar <mingo@elte.hu> writes:

> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> 
>> * Lee Revell <rlrevell@joe-job.com> wrote:
>> 
>> > File under boot-time stuff, I guess.  This could be bad if X crashes,
>> > but I can't remember the last time this happened to me, and I use xorg
>> > CVS.
>> 
>> but the first wbinvd() within prepare_set() seems completely unnecessary
>> - we can flush the cache after disabling the cache just fine.
>
> the third wbinvd() in post_set() seems unnecessary too - what kind of
> cache do we expect to flush, we've disabled caching in the CPU ... But
> the Intel pseudocode does it too - this is a thinko i think.

The multiple steps are needed, otherwise there can be problems
with hyperthreading (the first x86-64 didn't do it in all cases,
and it causes occassional problens with Intel CPUs) 

Also repeated calls of this are relatively cheap because at the
second time there is not much to flush anymore.

I would suggest to not do this change, it could cause very
subtle problems.

-Andi

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Andi Kleen]

Ingo Molnar <mingo@elte.hu> writes:

> The question is, does any of the Intel (or AMD) docs
> say that the CPU cache has to be write-back flushed when setting MTRRs,
> or were those calls only done out of paranoia?

Both the Intel and AMD docs require the cache flush for MTRR
caching attribute changes. 

At least in pageattr (which is related) i know of cases where
not doing them caused data corruption in real loads.

-Andi

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> >since the latency tracer does not trigger, we need a modified tracer to
> >find out what's happening during such long delays. I've attached the
> >'user-latency-tracer' patch ontop of -Q5, which is a modification of the
> >latency tracer.
> Grr. I should have checked before I built with this patch. With this in
> I now get the
>   kernel: Could not allocate 4 bytes percpu data
> messages again. Need to increase that data area so
>   #define PERCPU_ENOUGH_ROOM 196608
> or something similar (should leave about 50K free for modules).

ok, i've upped that value in my tree too.

> I will rebuild with this change plus the latest of the others.

since your traces do show those 'mystic' latency incidents causing
200-500 usec overhead in few-instructions code paths, perhaps the 1 msec
jitter you are seeing could a consequence of this too. So perhaps it
would make sense to first try disabling IDE DMA, to see whether this has
any effect on the magic latencies.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Mark_H_Johnson]

>since the latency tracer does not trigger, we need a modified tracer to
>find out what's happening during such long delays. I've attached the
>'user-latency-tracer' patch ontop of -Q5, which is a modification of the
>latency tracer.
Grr. I should have checked before I built with this patch. With this in
I now get the
  kernel: Could not allocate 4 bytes percpu data
messages again. Need to increase that data area so
  #define PERCPU_ENOUGH_ROOM 196608
or something similar (should leave about 50K free for modules).

I will rebuild with this change plus the latest of the others.

--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Takashi Iwai]

At Tue, 31 Aug 2004 20:48:46 +0200,
Ingo Molnar wrote:
> 
> 
> * Takashi Iwai <tiwai@suse.de> wrote:
> 
> > Does the attached patch fix this problem?
> > 
> > 
> > Takashi
> > 
> > --- linux/sound/pci/ens1370.c	25 Aug 2004 09:57:03 -0000	1.64
> > +++ linux/sound/pci/ens1370.c	31 Aug 2004 18:17:45 -0000
> > @@ -513,6 +513,7 @@
> >  		r = inl(ES_REG(ensoniq, 1371_SMPRATE));
> >  		if ((r & ES_1371_SRC_RAM_BUSY) == 0)
> >  			return r;
> > +		cond_resched();
> 
> but ... snd_es1371_wait_src_ready() is being called with
> ensoniq->reg_lock held and you must not reschedule with a spinlock held. 

Oh yes, you're right.  I overlooked that.

> cond_resched_lock(&ensoniq->req_lock) might not crash immediately, but 
> is it really safe to release the driver lock at this point?

The lock can be released, but then *_rate() functions may become racy
with each other.

Ok, the second try.


Takashi

--- linux/sound/pci/ens1370.c	25 Aug 2004 09:57:03 -0000	1.64
+++ linux/sound/pci/ens1370.c	31 Aug 2004 19:00:33 -0000
@@ -372,6 +372,7 @@
 
 struct _snd_ensoniq {
 	spinlock_t reg_lock;
+	struct semaphore src_mutex;
 
 	int irq;
 
@@ -513,6 +514,7 @@
 		r = inl(ES_REG(ensoniq, 1371_SMPRATE));
 		if ((r & ES_1371_SRC_RAM_BUSY) == 0)
 			return r;
+		cond_resched();
 	}
 	snd_printk("wait source ready timeout 0x%lx [0x%x]\n", ES_REG(ensoniq, 1371_SMPRATE), r);
 	return 0;
@@ -696,6 +698,7 @@
 {
 	unsigned int n, truncm, freq, result;
 
+	down(&ensoniq->src_mutex);
 	n = rate / 3000;
 	if ((1 << n) & ((1 << 15) | (1 << 13) | (1 << 11) | (1 << 9)))
 		n--;
@@ -719,12 +722,14 @@
 	snd_es1371_src_write(ensoniq, ES_SMPREG_ADC + ES_SMPREG_VFREQ_FRAC, freq & 0x7fff);
 	snd_es1371_src_write(ensoniq, ES_SMPREG_VOL_ADC, n << 8);
 	snd_es1371_src_write(ensoniq, ES_SMPREG_VOL_ADC + 1, n << 8);
+	up(&ensoniq->src_mutex);
 }
 
 static void snd_es1371_dac1_rate(ensoniq_t * ensoniq, unsigned int rate)
 {
 	unsigned int freq, r;
 
+	down(&ensoniq->src_mutex);
 	freq = ((rate << 15) + 1500) / 3000;
 	r = (snd_es1371_wait_src_ready(ensoniq) & (ES_1371_SRC_DISABLE | ES_1371_DIS_P2 | ES_1371_DIS_R1)) | ES_1371_DIS_P1;
 	outl(r, ES_REG(ensoniq, 1371_SMPRATE));
@@ -734,12 +739,14 @@
 	snd_es1371_src_write(ensoniq, ES_SMPREG_DAC1 + ES_SMPREG_VFREQ_FRAC, freq & 0x7fff);
 	r = (snd_es1371_wait_src_ready(ensoniq) & (ES_1371_SRC_DISABLE | ES_1371_DIS_P2 | ES_1371_DIS_R1));
 	outl(r, ES_REG(ensoniq, 1371_SMPRATE));
+	up(&ensoniq->src_mutex);
 }
 
 static void snd_es1371_dac2_rate(ensoniq_t * ensoniq, unsigned int rate)
 {
 	unsigned int freq, r;
 
+	down(&ensoniq->src_mutex);
 	freq = ((rate << 15) + 1500) / 3000;
 	r = (snd_es1371_wait_src_ready(ensoniq) & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 | ES_1371_DIS_R1)) | ES_1371_DIS_P2;
 	outl(r, ES_REG(ensoniq, 1371_SMPRATE));
@@ -749,6 +756,7 @@
 	snd_es1371_src_write(ensoniq, ES_SMPREG_DAC2 + ES_SMPREG_VFREQ_FRAC, freq & 0x7fff);
 	r = (snd_es1371_wait_src_ready(ensoniq) & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 | ES_1371_DIS_R1));
 	outl(r, ES_REG(ensoniq, 1371_SMPRATE));
+	up(&ensoniq->src_mutex);
 }
 
 #endif /* CHIP1371 */
@@ -870,11 +878,12 @@
 	case 44100: ensoniq->ctrl |= ES_1370_WTSRSEL(3); break;
 	default: snd_BUG();
 	}
-#else
-	snd_es1371_dac1_rate(ensoniq, runtime->rate);
 #endif
 	outl(ensoniq->ctrl, ES_REG(ensoniq, CONTROL));
 	spin_unlock_irq(&ensoniq->reg_lock);
+#ifndef CHIP1370
+	snd_es1371_dac1_rate(ensoniq, runtime->rate);
+#endif
 	return 0;
 }
 
@@ -908,11 +917,12 @@
 		ensoniq->ctrl |= ES_1370_PCLKDIVO(ES_1370_SRTODIV(runtime->rate));
 		ensoniq->u.es1370.pclkdiv_lock |= ES_MODE_PLAY2;
 	}
-#else
-	snd_es1371_dac2_rate(ensoniq, runtime->rate);
 #endif
 	outl(ensoniq->ctrl, ES_REG(ensoniq, CONTROL));
 	spin_unlock_irq(&ensoniq->reg_lock);
+#ifndef CHIP1370
+	snd_es1371_dac2_rate(ensoniq, runtime->rate);
+#endif
 	return 0;
 }
 
@@ -944,11 +954,12 @@
 		ensoniq->ctrl |= ES_1370_PCLKDIVO(ES_1370_SRTODIV(runtime->rate));
 		ensoniq->u.es1370.pclkdiv_lock |= ES_MODE_CAPTURE;
 	}
-#else
-	snd_es1371_adc_rate(ensoniq, runtime->rate);
 #endif
 	outl(ensoniq->ctrl, ES_REG(ensoniq, CONTROL));
 	spin_unlock_irq(&ensoniq->reg_lock);
+#ifndef CHIP1370
+	snd_es1371_adc_rate(ensoniq, runtime->rate);
+#endif
 	return 0;
 }
 
@@ -1886,6 +1897,7 @@
 	if (ensoniq == NULL)
 		return -ENOMEM;
 	spin_lock_init(&ensoniq->reg_lock);
+	init_MUTEX(&ensoniq->src_mutex);
 	ensoniq->card = card;
 	ensoniq->pci = pci;
 	ensoniq->irq = -1;

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Takashi Iwai <tiwai@suse.de> wrote:

> At Tue, 31 Aug 2004 14:09:33 -0400,
> Lee Revell wrote:
> > 
> > On Tue, 2004-08-31 at 13:20, Lee Revell wrote:
> > > Hmm, looks like the es1371 takes ~0.5 ms to set the DAC rate.  The ALSA
> > > team would probably be able to help.  Takashi, any ideas?
> > 
> > Ugh.  Please remove alsa-devel from any followups, as they seem to have
> > inadvertently enabled moderation.
> 
> IIRC, recently the moderation was disabled, so this should be no
> longer problem.

FYI, i still got 'your mail awaits moderation' messages just 2 minutes
ago.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Takashi Iwai]

At Tue, 31 Aug 2004 14:09:33 -0400,
Lee Revell wrote:
> 
> On Tue, 2004-08-31 at 13:20, Lee Revell wrote:
> > Hmm, looks like the es1371 takes ~0.5 ms to set the DAC rate.  The ALSA
> > team would probably be able to help.  Takashi, any ideas?
> 
> Ugh.  Please remove alsa-devel from any followups, as they seem to have
> inadvertently enabled moderation.

IIRC, recently the moderation was disabled, so this should be no
longer problem.


Takashi

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> Hmm, looks like the es1371 takes ~0.5 ms to set the DAC rate.  The
> ALSA team would probably be able to help.  Takashi, any ideas?

i'd suggest to postpone this issue for the time being, the SMP hardware
in question produces 'mysterious' latencies in other, very unexpected
places as well. I suspect there's some issue that hits whatever code
happens to run - and the es1371 driver is used for the latency testing. 
So i believe it's just an innocent bystander. I'd suggest to look at
these again if they pop up after the 'mysterious' latency source is
found.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Takashi Iwai <tiwai@suse.de> wrote:

> Does the attached patch fix this problem?
> 
> 
> Takashi
> 
> --- linux/sound/pci/ens1370.c	25 Aug 2004 09:57:03 -0000	1.64
> +++ linux/sound/pci/ens1370.c	31 Aug 2004 18:17:45 -0000
> @@ -513,6 +513,7 @@
>  		r = inl(ES_REG(ensoniq, 1371_SMPRATE));
>  		if ((r & ES_1371_SRC_RAM_BUSY) == 0)
>  			return r;
> +		cond_resched();

but ... snd_es1371_wait_src_ready() is being called with
ensoniq->reg_lock held and you must not reschedule with a spinlock held. 
cond_resched_lock(&ensoniq->req_lock) might not crash immediately, but 
is it really safe to release the driver lock at this point?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Takashi Iwai]

At Tue, 31 Aug 2004 13:20:19 -0400,
Lee Revell wrote:
> 
> On Tue, 2004-08-31 at 11:17, Mark_H_Johnson@raytheon.com wrote:
> > >I will be running some additional tests
> > >- reducing preempt_max_latency
> > >- running with sortirq and hardirq_preemption=0
> > >to see if these uncover any further problems.
> > 
> > #1 - audio driver
> >  latency: 621 us, entries: 28 (28)
> >     -----------------
> >     | task: latencytest/11492, uid:0 nice:0 policy:1 rt_prio:99
> >     -----------------
> >  => started at: snd_ensoniq_playback1_prepare+0x74/0x180
> >  => ended at:   snd_ensoniq_playback1_prepare+0x11d/0x180
> > =======>
> > 00000001 0.000ms (+0.000ms): snd_ensoniq_playback1_prepare
> > (snd_pcm_do_prepare)
> > 00000001 0.014ms (+0.014ms): snd_es1371_dac1_rate
> > (snd_ensoniq_playback1_prepare)
> > 00000001 0.014ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_dac1_rate)
> > 00000001 0.562ms (+0.548ms): snd_es1371_src_read (snd_es1371_dac1_rate)
> > 00000001 0.562ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_read)
> > 00000001 0.578ms (+0.015ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_read)
> > 00000001 0.585ms (+0.006ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> > 00000001 0.585ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_write)
> > 00000001 0.601ms (+0.015ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> > 00000001 0.601ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_write)
> > 00000001 0.602ms (+0.001ms): snd_es1371_wait_src_ready
> > (snd_es1371_dac1_rate)
> > 00000001 0.616ms (+0.013ms): smp_apic_timer_interrupt
> > (snd_ensoniq_playback1_prepare)
> > 
> > or
> > 
> >  latency: 663 us, entries: 41 (41)
> >     -----------------
> >     | task: latencytest/11492, uid:0 nice:0 policy:1 rt_prio:99
> >     -----------------
> >  => started at: snd_ensoniq_playback1_prepare+0x74/0x180
> >  => ended at:   snd_ensoniq_playback1_prepare+0x11d/0x180
> > =======>
> > 00000001 0.000ms (+0.000ms): snd_ensoniq_playback1_prepare
> > (snd_pcm_do_prepare)
> > 00000001 0.004ms (+0.004ms): snd_es1371_dac1_rate
> > (snd_ensoniq_playback1_prepare)
> > 00000001 0.005ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_dac1_rate)
> > 00000001 0.006ms (+0.001ms): snd_es1371_src_read (snd_es1371_dac1_rate)
> > 00000001 0.006ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_read)
> > 00000001 0.019ms (+0.012ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_read)
> > 00000001 0.607ms (+0.588ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> > 00000001 0.608ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_write)
> > 00000001 0.624ms (+0.016ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> > 00000001 0.624ms (+0.000ms): snd_es1371_wait_src_ready
> > (snd_es1371_src_write)
> > 00000001 0.626ms (+0.001ms): snd_es1371_wait_src_ready
> > (snd_es1371_dac1_rate)
> > 00000001 0.639ms (+0.013ms): smp_apic_timer_interrupt
> > (snd_ensoniq_playback1_prepare)
> 
> Hmm, looks like the es1371 takes ~0.5 ms to set the DAC rate.  The ALSA
> team would probably be able to help.  Takashi, any ideas?

Does the attached patch fix this problem?


Takashi

--- linux/sound/pci/ens1370.c	25 Aug 2004 09:57:03 -0000	1.64
+++ linux/sound/pci/ens1370.c	31 Aug 2004 18:17:45 -0000
@@ -513,6 +513,7 @@
 		r = inl(ES_REG(ensoniq, 1371_SMPRATE));
 		if ((r & ES_1371_SRC_RAM_BUSY) == 0)
 			return r;
+		cond_resched();
 	}
 	snd_printk("wait source ready timeout 0x%lx [0x%x]\n", ES_REG(ensoniq, 1371_SMPRATE), r);
 	return 0;

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 13:20, Lee Revell wrote:
> Hmm, looks like the es1371 takes ~0.5 ms to set the DAC rate.  The ALSA
> team would probably be able to help.  Takashi, any ideas?

Ugh.  Please remove alsa-devel from any followups, as they seem to have
inadvertently enabled moderation.

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Lee Revell]

On Tue, 2004-08-31 at 11:17, Mark_H_Johnson@raytheon.com wrote:
> >I will be running some additional tests
> >- reducing preempt_max_latency
> >- running with sortirq and hardirq_preemption=0
> >to see if these uncover any further problems.
> 
> #1 - audio driver
>  latency: 621 us, entries: 28 (28)
>     -----------------
>     | task: latencytest/11492, uid:0 nice:0 policy:1 rt_prio:99
>     -----------------
>  => started at: snd_ensoniq_playback1_prepare+0x74/0x180
>  => ended at:   snd_ensoniq_playback1_prepare+0x11d/0x180
> =======>
> 00000001 0.000ms (+0.000ms): snd_ensoniq_playback1_prepare
> (snd_pcm_do_prepare)
> 00000001 0.014ms (+0.014ms): snd_es1371_dac1_rate
> (snd_ensoniq_playback1_prepare)
> 00000001 0.014ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_dac1_rate)
> 00000001 0.562ms (+0.548ms): snd_es1371_src_read (snd_es1371_dac1_rate)
> 00000001 0.562ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_src_read)
> 00000001 0.578ms (+0.015ms): snd_es1371_wait_src_ready
> (snd_es1371_src_read)
> 00000001 0.585ms (+0.006ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> 00000001 0.585ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_src_write)
> 00000001 0.601ms (+0.015ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> 00000001 0.601ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_src_write)
> 00000001 0.602ms (+0.001ms): snd_es1371_wait_src_ready
> (snd_es1371_dac1_rate)
> 00000001 0.616ms (+0.013ms): smp_apic_timer_interrupt
> (snd_ensoniq_playback1_prepare)
> 
> or
> 
>  latency: 663 us, entries: 41 (41)
>     -----------------
>     | task: latencytest/11492, uid:0 nice:0 policy:1 rt_prio:99
>     -----------------
>  => started at: snd_ensoniq_playback1_prepare+0x74/0x180
>  => ended at:   snd_ensoniq_playback1_prepare+0x11d/0x180
> =======>
> 00000001 0.000ms (+0.000ms): snd_ensoniq_playback1_prepare
> (snd_pcm_do_prepare)
> 00000001 0.004ms (+0.004ms): snd_es1371_dac1_rate
> (snd_ensoniq_playback1_prepare)
> 00000001 0.005ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_dac1_rate)
> 00000001 0.006ms (+0.001ms): snd_es1371_src_read (snd_es1371_dac1_rate)
> 00000001 0.006ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_src_read)
> 00000001 0.019ms (+0.012ms): snd_es1371_wait_src_ready
> (snd_es1371_src_read)
> 00000001 0.607ms (+0.588ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> 00000001 0.608ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_src_write)
> 00000001 0.624ms (+0.016ms): snd_es1371_src_write (snd_es1371_dac1_rate)
> 00000001 0.624ms (+0.000ms): snd_es1371_wait_src_ready
> (snd_es1371_src_write)
> 00000001 0.626ms (+0.001ms): snd_es1371_wait_src_ready
> (snd_es1371_dac1_rate)
> 00000001 0.639ms (+0.013ms): smp_apic_timer_interrupt
> (snd_ensoniq_playback1_prepare)

Hmm, looks like the es1371 takes ~0.5 ms to set the DAC rate.  The ALSA
team would probably be able to help.  Takashi, any ideas?

Lee

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Mark_H_Johnson]

>I will be running some additional tests
>- reducing preempt_max_latency
>- running with sortirq and hardirq_preemption=0
>to see if these uncover any further problems.

Same system / kernel combination as described previously.

With preempt_max_latency=500, I went from a handful of traces to 63 in
a 25 minute test run. Most traces during the last half of the test while
the disk was active (write, copy, read). I will send a copy of the full
traces separately (not to linux-kernel), but here is a summary of the
information gathered. If someone else wants the full traces, please send
an email separately.

Note - I did not repeat the network poll / number of read cycles
problem since we are already working that one.

Cascade
=======
Occurred five times, with latencies of
 latency: 964 us, entries: 285 (285)
 latency: 964 us, entries: 285 (285)
 latency: 1827 us, entries: 454 (454)
 latency: 1111 us, entries: 318 (318)
 latency: 969 us, entries: 279 (279)

Starts / ends at
 => started at: run_timer_softirq+0x12f/0x2a0
 => ended at:   run_timer_softirq+0x10a/0x2a0

For example:
00000001 0.000ms (+0.000ms): run_timer_softirq (___do_softirq)
00000001 0.000ms (+0.000ms): cascade (run_timer_softirq)
00000001 0.005ms (+0.004ms): cascade (run_timer_softirq)
00000001 0.009ms (+0.004ms): cascade (run_timer_softirq)
00000001 0.013ms (+0.004ms): cascade (run_timer_softirq)
00000001 0.018ms (+0.004ms): cascade (run_timer_softirq)
...
00000001 0.891ms (+0.004ms): cascade (run_timer_softirq)
00000001 0.895ms (+0.004ms): cascade (run_timer_softirq)
00000001 0.896ms (+0.000ms): internal_add_timer (cascade)
00010001 0.899ms (+0.003ms): do_IRQ (run_timer_softirq)
00010002 0.899ms (+0.000ms): mask_and_ack_level_ioapic_irq (do_IRQ)
00010002 0.899ms (+0.000ms): mask_IO_APIC_irq
(mask_and_ack_level_ioapic_irq)
00010003 0.900ms (+0.000ms): __mask_IO_APIC_irq (mask_IO_APIC_irq)
00010003 0.900ms (+0.000ms): __modify_IO_APIC_irq (__mask_IO_APIC_irq)
00010002 0.914ms (+0.013ms): generic_redirect_hardirq (do_IRQ)
...


Long Duration Trace Entries
===========================

Each of these traces had a delay of about 1/2 msec at one step.

#1 - audio driver
 latency: 621 us, entries: 28 (28)
    -----------------
    | task: latencytest/11492, uid:0 nice:0 policy:1 rt_prio:99
    -----------------
 => started at: snd_ensoniq_playback1_prepare+0x74/0x180
 => ended at:   snd_ensoniq_playback1_prepare+0x11d/0x180
=======>
00000001 0.000ms (+0.000ms): snd_ensoniq_playback1_prepare
(snd_pcm_do_prepare)
00000001 0.014ms (+0.014ms): snd_es1371_dac1_rate
(snd_ensoniq_playback1_prepare)
00000001 0.014ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_dac1_rate)
00000001 0.562ms (+0.548ms): snd_es1371_src_read (snd_es1371_dac1_rate)
00000001 0.562ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_src_read)
00000001 0.578ms (+0.015ms): snd_es1371_wait_src_ready
(snd_es1371_src_read)
00000001 0.585ms (+0.006ms): snd_es1371_src_write (snd_es1371_dac1_rate)
00000001 0.585ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_src_write)
00000001 0.601ms (+0.015ms): snd_es1371_src_write (snd_es1371_dac1_rate)
00000001 0.601ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_src_write)
00000001 0.602ms (+0.001ms): snd_es1371_wait_src_ready
(snd_es1371_dac1_rate)
00000001 0.616ms (+0.013ms): smp_apic_timer_interrupt
(snd_ensoniq_playback1_prepare)

or

 latency: 663 us, entries: 41 (41)
    -----------------
    | task: latencytest/11492, uid:0 nice:0 policy:1 rt_prio:99
    -----------------
 => started at: snd_ensoniq_playback1_prepare+0x74/0x180
 => ended at:   snd_ensoniq_playback1_prepare+0x11d/0x180
=======>
00000001 0.000ms (+0.000ms): snd_ensoniq_playback1_prepare
(snd_pcm_do_prepare)
00000001 0.004ms (+0.004ms): snd_es1371_dac1_rate
(snd_ensoniq_playback1_prepare)
00000001 0.005ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_dac1_rate)
00000001 0.006ms (+0.001ms): snd_es1371_src_read (snd_es1371_dac1_rate)
00000001 0.006ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_src_read)
00000001 0.019ms (+0.012ms): snd_es1371_wait_src_ready
(snd_es1371_src_read)
00000001 0.607ms (+0.588ms): snd_es1371_src_write (snd_es1371_dac1_rate)
00000001 0.608ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_src_write)
00000001 0.624ms (+0.016ms): snd_es1371_src_write (snd_es1371_dac1_rate)
00000001 0.624ms (+0.000ms): snd_es1371_wait_src_ready
(snd_es1371_src_write)
00000001 0.626ms (+0.001ms): snd_es1371_wait_src_ready
(snd_es1371_dac1_rate)
00000001 0.639ms (+0.013ms): smp_apic_timer_interrupt
(snd_ensoniq_playback1_prepare)

#2 - Scheduler

preemption latency trace v1.0.2
-------------------------------
 latency: 567 us, entries: 48 (48)
    -----------------
    | task: cpu_burn/9444, uid:0 nice:10 policy:0 rt_prio:0
    -----------------
 => started at: schedule+0x51/0x7b0
 => ended at:   schedule+0x35b/0x7b0
=======>
00000001 0.000ms (+0.000ms): schedule (io_schedule)
00000001 0.001ms (+0.001ms): sched_clock (schedule)
00000002 0.001ms (+0.000ms): deactivate_task (schedule)
00000002 0.002ms (+0.000ms): dequeue_task (deactivate_task)
00000002 0.549ms (+0.546ms): __switch_to (schedule)
00000002 0.550ms (+0.001ms): finish_task_switch (schedule)
00000002 0.550ms (+0.000ms): smp_apic_timer_interrupt (finish_task_switch)
00010002 0.551ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010002 0.551ms (+0.000ms): profile_hook (profile_tick)

[I have a LOT more traces where __switch_to has the big time delay]
but also note...

preemption latency trace v1.0.2
-------------------------------
 latency: 591 us, entries: 62 (62)
    -----------------
    | task: fam/4524, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: schedule+0x51/0x7b0
 => ended at:   schedule+0x35b/0x7b0
=======>
00000001 0.000ms (+0.000ms): schedule (io_schedule)
00000001 0.000ms (+0.000ms): sched_clock (schedule)
00000002 0.066ms (+0.066ms): deactivate_task (schedule)
00000002 0.066ms (+0.000ms): dequeue_task (deactivate_task)
00000002 0.475ms (+0.408ms): dequeue_task (schedule)
00000002 0.475ms (+0.000ms): recalc_task_prio (schedule)
00000002 0.475ms (+0.000ms): effective_prio (recalc_task_prio)
00000002 0.475ms (+0.000ms): enqueue_task (schedule)
00000002 0.557ms (+0.081ms): __switch_to (schedule)
00000002 0.558ms (+0.000ms): finish_task_switch (schedule)
00000002 0.558ms (+0.000ms): smp_apic_timer_interrupt (finish_task_switch)
00010002 0.559ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
where dequeue_task can take a while as well or this one

preemption latency trace v1.0.2
-------------------------------
 latency: 591 us, entries: 77 (77)
    -----------------
    | task: ksoftirqd/0/3, uid:0 nice:-10 policy:0 rt_prio:0
    -----------------
 => started at: schedule+0x51/0x7b0
 => ended at:   schedule+0x35b/0x7b0
=======>
00000001 0.000ms (+0.000ms): schedule (io_schedule)
00000001 0.000ms (+0.000ms): sched_clock (schedule)
00000002 0.000ms (+0.000ms): deactivate_task (schedule)
00000002 0.000ms (+0.000ms): dequeue_task (deactivate_task)
00000002 0.480ms (+0.479ms): load_balance_newidle (schedule)
00000002 0.514ms (+0.034ms): find_busiest_group (load_balance_newidle)
00000002 0.554ms (+0.039ms): find_next_bit (find_busiest_group)
00000002 0.555ms (+0.001ms): find_next_bit (find_busiest_group)
00000002 0.555ms (+0.000ms): find_busiest_queue (load_balance_newidle)
00000002 0.556ms (+0.000ms): find_next_bit (find_busiest_queue)
00000002 0.557ms (+0.000ms): double_lock_balance (load_balance_newidle)
00000003 0.557ms (+0.000ms): move_tasks (load_balance_newidle)
00000003 0.559ms (+0.002ms): find_next_bit (move_tasks)
00000003 0.560ms (+0.000ms): find_next_bit (move_tasks)
00000003 0.561ms (+0.000ms): find_next_bit (move_tasks)
04000002 0.563ms (+0.002ms): __switch_to (schedule)
04000002 0.564ms (+0.000ms): finish_task_switch (schedule)

where it appears load balancing takes a long time.

#3 - kmap / kunmap

preemption latency trace v1.0.2
-------------------------------
 latency: 602 us, entries: 53 (53)
    -----------------
    | task: cp/11501, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: kmap_atomic+0x23/0xe0
 => ended at:   kunmap_atomic+0x7b/0xa0
=======>
00000001 0.000ms (+0.000ms): kmap_atomic (file_read_actor)
00000001 0.000ms (+0.000ms): page_address (file_read_actor)
00000001 0.000ms (+0.000ms): __copy_to_user_ll (file_read_actor)
00000001 0.502ms (+0.501ms): smp_apic_timer_interrupt (__copy_to_user_ll)
00010001 0.502ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 0.502ms (+0.000ms): profile_hook (profile_tick)
00010002 0.502ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 0.570ms (+0.068ms): profile_hit (smp_apic_timer_interrupt)
00010001 0.571ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 0.571ms (+0.000ms): update_one_process (update_process_times)
00010001 0.571ms (+0.000ms): run_local_timers (update_process_times)

or

preemption latency trace v1.0.2
-------------------------------
 latency: 615 us, entries: 75 (75)
    -----------------
    | task: cat/11844, uid:0 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: kmap_atomic+0x23/0xe0
 => ended at:   kunmap_atomic+0x7b/0xa0
=======>
00000001 0.000ms (+0.000ms): kmap_atomic (file_read_actor)
00000001 0.000ms (+0.000ms): page_address (file_read_actor)
00000001 0.000ms (+0.000ms): __copy_to_user_ll (file_read_actor)
00000001 0.563ms (+0.562ms): smp_apic_timer_interrupt (__copy_to_user_ll)
00010001 0.563ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 0.563ms (+0.000ms): profile_hook (profile_tick)
00010002 0.564ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 0.564ms (+0.000ms): profile_hit (smp_apic_timer_interrupt)
00010001 0.564ms (+0.000ms): update_process_times
(smp_apic_timer_interrupt)
00010001 0.564ms (+0.000ms): update_one_process (update_process_times)

#4 - mmap

preemption latency trace v1.0.2
-------------------------------
 latency: 660 us, entries: 48 (48)
    -----------------
    | task: get_ltrace.sh/12120, uid:0 nice:-20 policy:0 rt_prio:0
    -----------------
 => started at: cond_resched_lock+0x7b/0x140
 => ended at:   exit_mmap+0x168/0x210
=======>
00000001 0.000ms (+0.000ms): touch_preempt_timing (cond_resched_lock)
00000001 0.000ms (+0.000ms): __bitmap_weight (unmap_vmas)
00000001 0.000ms (+0.000ms): vm_acct_memory (exit_mmap)
00000001 0.001ms (+0.000ms): clear_page_tables (exit_mmap)
00010001 0.520ms (+0.518ms): do_IRQ (clear_page_tables)
00010002 0.564ms (+0.044ms): ack_edge_ioapic_irq (do_IRQ)
00010002 0.564ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010001 0.564ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010001 0.564ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010002 0.565ms (+0.001ms): mark_offset_tsc (timer_interrupt)
00010002 0.618ms (+0.052ms): do_timer (timer_interrupt)
00010002 0.618ms (+0.000ms): update_wall_time (do_timer)
00010002 0.618ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010002 0.619ms (+0.000ms): generic_note_interrupt (do_IRQ)
00010002 0.619ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00000002 0.619ms (+0.000ms): do_softirq (do_IRQ)

#5 - network poll

preemption latency trace v1.0.2
-------------------------------
 latency: 753 us, entries: 371 (371)
    -----------------
    | task: ksoftirqd/1/5, uid:0 nice:-10 policy:0 rt_prio:0
    -----------------
 => started at: rtl8139_poll+0x3c/0x160
 => ended at:   rtl8139_poll+0x100/0x160
=======>
00000001 0.000ms (+0.000ms): rtl8139_poll (net_rx_action)
00000001 0.000ms (+0.000ms): rtl8139_rx (rtl8139_poll)
00000001 0.002ms (+0.001ms): alloc_skb (rtl8139_rx)
00000001 0.002ms (+0.000ms): kmem_cache_alloc (alloc_skb)
00000001 0.002ms (+0.000ms): __kmalloc (alloc_skb)
00000001 0.004ms (+0.002ms): eth_type_trans (rtl8139_rx)
00000001 0.005ms (+0.000ms): netif_receive_skb (rtl8139_rx)
00000002 0.008ms (+0.002ms): packet_rcv_spkt (netif_receive_skb)
00000002 0.008ms (+0.000ms): skb_clone (packet_rcv_spkt)
00000002 0.009ms (+0.000ms): kmem_cache_alloc (skb_clone)
00000002 0.078ms (+0.069ms): memcpy (skb_clone)
00010002 0.498ms (+0.419ms): do_IRQ (skb_clone)
00010003 0.498ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010003 0.498ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010002 0.499ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010002 0.499ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010003 0.568ms (+0.068ms): mark_offset_tsc (timer_interrupt)
00010003 0.582ms (+0.014ms): do_timer (timer_interrupt)
00010003 0.582ms (+0.000ms): update_wall_time (do_timer)

or

preemption latency trace v1.0.2
-------------------------------
 latency: 752 us, entries: 395 (395)
    -----------------
    | task: ksoftirqd/1/5, uid:0 nice:-10 policy:0 rt_prio:0
    -----------------
 => started at: rtl8139_poll+0x3c/0x160
 => ended at:   rtl8139_poll+0x100/0x160
=======>
00000001 0.000ms (+0.000ms): rtl8139_poll (net_rx_action)
00000001 0.000ms (+0.000ms): rtl8139_rx (rtl8139_poll)
00000001 0.002ms (+0.001ms): alloc_skb (rtl8139_rx)
00000001 0.002ms (+0.000ms): kmem_cache_alloc (alloc_skb)
00000001 0.002ms (+0.000ms): __kmalloc (alloc_skb)
00000001 0.005ms (+0.002ms): eth_type_trans (rtl8139_rx)
00000001 0.146ms (+0.140ms): netif_receive_skb (rtl8139_rx)
00000002 0.566ms (+0.420ms): packet_rcv_spkt (netif_receive_skb)
00000002 0.567ms (+0.000ms): skb_clone (packet_rcv_spkt)
00000002 0.567ms (+0.000ms): kmem_cache_alloc (skb_clone)
00000002 0.568ms (+0.000ms): memcpy (skb_clone)
00000002 0.570ms (+0.001ms): strlcpy (packet_rcv_spkt)

Separately I ran a series of tests with:
  preempt_max_latency=500
  hardirq_preemption=0
  softirq_preemption=0
which should be similar to the configuration I used in 2.4 kernels.
There were > 100 latency traces (my script stops at 100) in the same
25 minute test. In addition to the traces listed above, I had the
following problems.

RT Run Flush
============

preemption latency trace v1.0.2
-------------------------------
 latency: 1592 us, entries: 4000 (6306)
    -----------------
    | task: latencytest/6440, uid:0 nice:0 policy:1 rt_prio:99
    -----------------
 => started at: smp_apic_timer_interrupt+0x43/0x130
 => ended at:   smp_apic_timer_interrupt+0xaa/0x130

...
00000101 0.041ms (+0.001ms): add_entropy_words (extract_entropy)
00000101 0.042ms (+0.000ms): SHATransform (extract_entropy)
00000101 0.042ms (+0.000ms): memcpy (SHATransform)
00000101 0.044ms (+0.001ms): add_entropy_words (extract_entropy)
00000101 0.045ms (+0.000ms): add_entropy_words (extract_entropy)
00000101 0.046ms (+0.001ms): credit_entropy_store (extract_entropy)
00000102 0.047ms (+0.001ms): __wake_up (extract_entropy)
00000103 0.047ms (+0.000ms): __wake_up_common (__wake_up)
00000101 0.048ms (+0.000ms): SHATransform (extract_entropy)
00000101 0.048ms (+0.000ms): memcpy (SHATransform)
00000101 0.050ms (+0.001ms): add_entropy_words (extract_entropy)
00000101 0.050ms (+0.000ms): SHATransform (extract_entropy)
00000101 0.050ms (+0.000ms): memcpy (SHATransform)
00000101 0.052ms (+0.001ms): add_entropy_words (extract_entropy)
00000201 0.053ms (+0.001ms): local_bh_enable (rt_run_flush)
00000101 0.053ms (+0.000ms): cond_resched_all (rt_run_flush)
00000101 0.053ms (+0.000ms): cond_resched_softirq (rt_run_flush)
00000201 0.054ms (+0.000ms): local_bh_enable (rt_run_flush)
00000101 0.054ms (+0.000ms): cond_resched_all (rt_run_flush)
00000101 0.054ms (+0.000ms): cond_resched_softirq (rt_run_flush)
... the last 3 lines repeat over 1000 times and fill
the trace buffer completely ...

The above sequence occurred twice during testing.

Short But Long
==============

preemption latency trace v1.0.2
-------------------------------
 latency: 549 us, entries: 4 (4)
    -----------------
    | task: kblockd/1/11, uid:0 nice:-10 policy:0 rt_prio:0
    -----------------
 => started at: worker_thread+0x22d/0x3a0
 => ended at:   worker_thread+0x2a2/0x3a0
=======>
00000001 0.000ms (+0.000ms): worker_thread (kthread)
00000001 0.000ms (+0.000ms): __wake_up (worker_thread)
00000002 0.549ms (+0.549ms): __wake_up_common (__wake_up)
00000001 0.550ms (+0.000ms): sub_preempt_count (worker_thread)

or

preemption latency trace v1.0.2
-------------------------------
 latency: 551 us, entries: 4 (4)
    -----------------
    | task: kblockd/1/11, uid:0 nice:-10 policy:0 rt_prio:0
    -----------------
 => started at: worker_thread+0x22d/0x3a0
 => ended at:   worker_thread+0x2a2/0x3a0
=======>
00000001 0.000ms (+0.000ms): worker_thread (kthread)
00000001 0.000ms (+0.000ms): __wake_up (worker_thread)
00000002 0.000ms (+0.000ms): __wake_up_common (__wake_up)
00000001 0.552ms (+0.551ms): sub_preempt_count (worker_thread)

or this one apparently preempting the real time task [why??]
Now that I look, the first set of tests preempted the max priority
real time application six (6) times and the second set of tests
preempted the RT application thirty (30) times.

preemption latency trace v1.0.2
-------------------------------
 latency: 566 us, entries: 13 (13)
    -----------------
    | task: latencytest/7959, uid:0 nice:0 policy:1 rt_prio:99
    -----------------
 => started at: do_IRQ+0x19/0x290
 => ended at:   do_IRQ+0x1cf/0x290
=======>
00010000 0.000ms (+0.000ms): do_IRQ (common_interrupt)
00010000 0.000ms (+0.000ms): do_IRQ (<08049b20>)
00010001 0.000ms (+0.000ms): ack_edge_ioapic_irq (do_IRQ)
00010001 0.000ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010000 0.000ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
00010000 0.001ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
00010001 0.549ms (+0.548ms): mark_offset_tsc (timer_interrupt)
00010001 0.564ms (+0.014ms): do_timer (timer_interrupt)
00010001 0.564ms (+0.000ms): update_wall_time (do_timer)
00010001 0.564ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010001 0.565ms (+0.001ms): generic_note_interrupt (do_IRQ)
00010001 0.566ms (+0.000ms): end_edge_ioapic_irq (do_IRQ)
00000001 0.566ms (+0.000ms): sub_preempt_count (do_IRQ)

Another Long Time
=================

#1 - kmap / kunmap

Similar stop / end locations to above, but a different cause.

preemption latency trace v1.0.2
-------------------------------
 latency: 696 us, entries: 131 (131)
    -----------------
    | task: sleep/8854, uid:0 nice:-20 policy:0 rt_prio:0
    -----------------
 => started at: kmap_atomic+0x23/0xe0
 => ended at:   kunmap_atomic+0x7b/0xa0
=======>
00000001 0.000ms (+0.000ms): kmap_atomic (do_anonymous_page)
00000001 0.000ms (+0.000ms): page_address (do_anonymous_page)
00010001 0.413ms (+0.413ms): do_IRQ (do_anonymous_page)
00010002 0.452ms (+0.038ms): ack_edge_ioapic_irq (do_IRQ)
00010002 0.452ms (+0.000ms): generic_redirect_hardirq (do_IRQ)
00010001 0.454ms (+0.001ms): generic_handle_IRQ_event (do_IRQ)
00010001 0.488ms (+0.034ms): timer_interrupt (generic_handle_IRQ_event)
00010002 0.557ms (+0.069ms): mark_offset_tsc (timer_interrupt)
00010002 0.573ms (+0.015ms): do_timer (timer_interrupt)
00010002 0.574ms (+0.000ms): update_wall_time (do_timer)
00010002 0.574ms (+0.000ms): update_wall_time_one_tick (update_wall_time)

Perhaps the most disturbing finding tat the max priority RT application
can get preempted for a long time, even though there is:
 - only one real time task
 - two CPU's to do work

  --Mark

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Mark_H_Johnson]

>in theory the patch is more or less equivalent to setting
>netdev_max_backlog to a value of 1 - could you try that setting too?
>(with the patch unapplied.)

Ugh. That setting is VERY BAD. Just a quick test without
doing anything complex...
  # echo 1 > /proc/sys/net/core/netdev_max_backlog
  # ping dws7
  PING dws7 (192.52.215.17) 56(84) bytes of data.
[so the DNS lookup worked]
  From dws77... (192.52.215.87) icmp_seq=0 Destination Host Unreachable
  From dws77... (192.52.215.87) icmp_seq=1 Destination Host Unreachable
  From dws77... (192.52.215.87) icmp_seq=2 Destination Host Unreachable
  ...
[NOTE - these are plugged into the same 10/100 Ethernet switch]
  # echo 8 > /proc/sys/net/core/netdev_max_backlog
  # ping dws7
  PING dws7 (192.52.215.17) 56(84) bytes of data.
[so the DNS lookup worked]
  From dws77... (192.52.215.87) icmp_seq=0 ttl=64 time=2210 ms
  From dws77... (192.52.215.87) icmp_seq=1 ttl=64 time=1210 ms
  From dws77... (192.52.215.87) icmp_seq=2 ttl=64 time=210 ms
  From dws77... (192.52.215.87) icmp_seq=2 ttl=64 time=0.355 ms
  From dws77... (192.52.215.87) icmp_seq=2 ttl=64 time=0.397 ms
  ...
I tried again with 2, 3, and 4. Two appears to be "way too small" with
a ping of 1000 ms and nominal values of 0.800 ms. Three does not appear
to be good either with nominal values of 0.500 ms. Four has similar
results to eight (8).


--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]


* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> VARYING SYSTEM CALL TIMES
> =========================
> 
> In 2.4, it appears that the duration of the write system call is
> basically fixed and dependent on the duration of the audio fragment.
> In 2.6, this behavior is now different. If I look at the chart in
> detail, it appears the system is queueing up several write operations
> during the first few seconds of testing. You can see this by
> consistently low elapsed times for the write system call. Then the
> elapsed time for the write bounces up / down in a sawtooth pattern
> over a 1 msec range. Could someone explain the cause of this new
> behavior and if there is a setting to restore the old behavior? I am
> concerned that this queueing adds latency to audio operations (when
> trying to synchronize audio with other real time behavior).

since the latency tracer does not trigger, we need a modified tracer to
find out what's happening during such long delays. I've attached the
'user-latency-tracer' patch ontop of -Q5, which is a modification of the
latency tracer. This patch enables free-running tracing which includes
all kernel functions not just critical sections. To activate this, two
things have to be done. Firstly:

	echo 2 > /proc/sys/kernel/trace_enabled

this turns off the normal latency tracer and turns on the 'user tracer'. 
Traces can be generated by userspace via a hack done to
sys_gettimeofday():

	gettimeofday(0,1); // enable the tracer
	gettimeofday(0,0); // save current trace and disable the tracer

this way the tracing can be limited to the suspected codepaths only.

could you try to insert gettimeofday(0,1) into your testsuite just
before the write() call is done, and right after the write() call, and
save a couple of representative traces? The patch also ups the # of
latency entries to 8000 - if that is still insufficient then please
increase it as needed.

NOTE: on SMP the tracing on/off is strictly per-CPU. So do the enabling
and disabling of the trace on the same CPU. (doing otherwise wont cause
problems, but the generated traces will be less useful.)

	Ingo

[-- Attachment #2: user-latency-2.6.9-rc1-bk4-Q5-A0 --]
[-- Type: text/plain, Size: 3598 bytes --]

--- linux/kernel/latency.c.orig
+++ linux/kernel/latency.c
@@ -27,7 +27,7 @@ static DECLARE_MUTEX(max_mutex);
 
 #ifdef CONFIG_LATENCY_TRACE
 
-#define MAX_TRACE 4000UL
+#define MAX_TRACE 8000UL
 
 struct trace_entry {
 	unsigned long preempt_count;
@@ -63,14 +63,13 @@ static unsigned long max_nice;
 static unsigned long max_policy;
 static unsigned long max_rt_priority;
 
-inline void notrace
+static inline void notrace
 ____trace(struct cpu_trace *tr, unsigned long eip, unsigned long parent_eip)
 {
 	struct trace_entry *entry;
 
-	BUG_ON(!irqs_disabled());
-
-	if (tr->trace_idx < MAX_TRACE) {
+	if ((tr->critical_start || (trace_enabled == 2)) &&
+			(tr->trace_idx < MAX_TRACE)) {
 		entry = tr->trace + tr->trace_idx;
 		entry->eip = eip;
 		entry->parent_eip = parent_eip;
@@ -80,7 +79,7 @@ ____trace(struct cpu_trace *tr, unsigned
 	tr->trace_idx++;
 }
 
-inline void notrace
+static inline void notrace
 ___trace(unsigned long eip, unsigned long parent_eip)
 {
 	unsigned long flags;
@@ -266,6 +265,18 @@ static int setup_preempt_thresh(char *s)
 }
 __setup("preempt_thresh=", setup_preempt_thresh);
 
+static void update_max_trace(struct cpu_trace *tr)
+{
+	memcpy(&max_trace, tr, sizeof (max_trace));
+
+	memcpy(max_comm, current->comm, 16);
+	max_pid = current->pid;
+	max_uid = current->uid;
+	max_nice = current->static_prio - 20 - MAX_RT_PRIO;
+	max_policy = current->policy;
+	max_rt_priority = current->rt_priority;
+}
+
 static void notrace check_preempt_timing(struct cpu_trace *tr)
 {
 #ifdef CONFIG_LATENCY_TRACE
@@ -274,6 +285,10 @@ static void notrace check_preempt_timing
 	unsigned long parent_eip = (unsigned long)__builtin_return_address(1);
 	unsigned long latency;
 
+#ifdef CONFIG_LATENCY_TRACE
+	if (trace_enabled == 2)
+		return;
+#endif
 	atomic_inc(&tr->disabled);
 	latency = cycles_to_usecs(get_cycles() - tr->preempt_timestamp);
 
@@ -293,14 +308,7 @@ static void notrace check_preempt_timing
 
 #ifdef CONFIG_LATENCY_TRACE
 	____trace(tr, eip, parent_eip);
-	memcpy(&max_trace, tr, sizeof (max_trace));
-
-	memcpy(max_comm, current->comm, 16);
-	max_pid = current->pid;
-	max_uid = current->uid;
-	max_nice = current->static_prio - 20 - MAX_RT_PRIO;
-	max_policy = current->policy;
-	max_rt_priority = current->rt_priority;
+	update_max_trace(tr);
 #endif
 
 	if (preempt_thresh)
@@ -354,6 +362,10 @@ void notrace add_preempt_count(int val)
 #endif
 
 	preempt_count() += val;
+#ifdef CONFIG_LATENCY_TRACE
+	if (trace_enabled == 2)
+		return;
+#endif
 	if (preempt_count() == val) {
 		struct cpu_trace *tr = &__get_cpu_var(trace);
 
@@ -383,3 +395,27 @@ void notrace sub_preempt_count(int val)
 	preempt_count() -= val;
 }
 EXPORT_SYMBOL(sub_preempt_count);
+
+void user_trace_start(void)
+{
+	struct cpu_trace *tr;
+
+	if (trace_enabled != 2)
+		return;
+	tr = &get_cpu_var(trace);
+	tr->trace_idx = 0;
+	mcount();
+	put_cpu_var(trace);
+}
+
+void user_trace_stop(void)
+{
+	struct cpu_trace *tr;
+
+	if (trace_enabled != 2)
+		return;
+	tr = &get_cpu_var(trace);
+	mcount();
+	update_max_trace(tr);
+	put_cpu_var(trace);
+}
--- linux/kernel/time.c.orig2	
+++ linux/kernel/time.c	
@@ -90,8 +90,17 @@ asmlinkage long sys_stime(time_t __user 
 
 #endif /* __ARCH_WANT_SYS_TIME */
 
+extern void user_trace_start(void);
+extern void user_trace_stop(void);
+
 asmlinkage long sys_gettimeofday(struct timeval __user *tv, struct timezone __user *tz)
 {
+#ifdef CONFIG_LATENCY_TRACE
+	if (!tv && ((int)tz == 1))
+		user_trace_start();
+	if (!tv && !tz)
+		user_trace_stop();
+#endif
 	if (likely(tv != NULL)) {
 		struct timeval ktv;
 		do_gettimeofday(&ktv);

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

* Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:

> >regarding this particular latency, could you try the attached patch
> >ontop of -Q5? It turns the ->poll() loop into separate, individually
> >preemptable iterations instead of one batch of processing. In theory
> >this should result in latency being lower regardless of the
> >netdev_max_backlog value.
> 
> First time - stopped during init script - when trying to start a network
> service (automount).

in theory the patch is more or less equivalent to setting
netdev_max_backlog to a value of 1 - could you try that setting too?
(with the patch unapplied.)

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Mark_H_Johnson]

>regarding this particular latency, could you try the attached patch
>ontop of -Q5? It turns the ->poll() loop into separate, individually
>preemptable iterations instead of one batch of processing. In theory
>this should result in latency being lower regardless of the
>netdev_max_backlog value.

First time - stopped during init script - when trying to start a network
service (automount).
Second time - stopped during init script - did not get the "OK" for
bringing up interface eth0.
Alt-SysRq-P still does not show any data [not sure why].
Alt-SysRq-T captured data - for example, shows dhclient in sys_select ->
__pollwait -> do_select -> process_timeout -> add_wait_queue ->
schedule_timeout -> __mod_timer. Very odd, almost every other task (except
initlog) is stuck in one of:
 - generic_handle_IRQ_event
 - sub_preempt_count
 - do_irqd
 - do_hardirq
and all the tasks I can see have "S" status.
Third time - ditto - back to stopping at automount start up.
Alt-SysRq-T captured data, again everything I could look at in "S" mode.
In all three cases, another system attempting to "ping" the system under
test failed to get any responses.

In all cases, Ctrl-Alt-Del was good enough to get a clean reboot.

This looks like a bad patch; will go back to the last good kernel for
further testing.

--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]


* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> LONG NETWORK LATENCIES
> ======================
> 
> In about 25 minutes of heavy testing, I had two latency traces with
> /proc/sys/kernel/preempt_max_latency set to 700. They had the same start /
> end location with the long delay as follows:
>   730 us, entries: 361
>   ...
>   started at rtl8139_poll+0x3c/0x160
>   ended at   rtl8139_poll+0x100/0x160

regarding this particular latency, could you try the attached patch
ontop of -Q5? It turns the ->poll() loop into separate, individually
preemptable iterations instead of one batch of processing. In theory
this should result in latency being lower regardless of the
netdev_max_backlog value.

	Ingo

[-- Attachment #2: 2 --]
[-- Type: text/plain, Size: 738 bytes --]

--- linux/net/core/dev.c.orig2	
+++ linux/net/core/dev.c	
@@ -1903,7 +1903,7 @@ static void net_rx_action(struct softirq
 {
 	struct softnet_data *queue = &__get_cpu_var(softnet_data);
 	unsigned long start_time = jiffies;
-	int budget = netdev_max_backlog;
+	int budget = netdev_max_backlog, loops;
 
 	
 	local_irq_disable();
@@ -1926,7 +1926,10 @@ static void net_rx_action(struct softirq
 		dev = list_entry(queue->poll_list.next,
 				 struct net_device, poll_list);
 
-		if (dev->quota <= 0 || dev->poll(dev, &budget)) {
+		loops = 1;
+		if (dev->quota <= 0 || dev->poll(dev, &loops)) {
+			if (loops < 1)
+				budget--;
 			local_irq_disable();
 			list_del(&dev->poll_list);
 			list_add_tail(&dev->poll_list, &queue->poll_list);

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

[Mark_H_Johnson]

>i've uploaded -Q5 to:
> [snip the rest...]

Thanks.

This appears to be the first 2.6.x kernel I've run that has results
comparable to 2.4.x kernels with low latency patches and kernel preemption.
The few remaining symptoms I see include:

 - a few long (> 1 msec) delays in the real time CPU loop (no system calls)
 - varying time to complete the write system call (for audio) - much
different than 2.4
 - a couple latency traces (> 700 usec) in the network driver

For reference, these tests were performed on the following SMP system:
  Dual 866 Mhz Pentium III
  512 Mbyte memory
  IDE system disk (DMA enabled)
The basic test is Benno's latency test
(http://www.gardena.net/benno/linux/audio) with some slight modifications
to the tests to keep the second CPU busy (non real time CPU burner) and to
add network I/O tests. The 2.4 tests were run with 2.4.20, the 2.6 tests
were run with 2.4.9-rc1-Q5. On 2.6, voluntary_preemption,
kernel_preemption, hardirq_preemption, and softirq_preemption are all 1. I
also set
  /sys/block/hda/queue/max_sectors_kb = 32
  /sys/block/hda/queue/read_ahead_kb = 32
  /proc/sys/net/core/netdev_max_backlog = 8
and the audio driver was set to be non-threaded.

BASIC RESULTS
=============
Comparison of results between 2.6.x and 2.4.x; values in milliseconds.
Nominal values for the write operation is 1.45 msec; the CPU loop is 1.16
msec.

          Max CPU Delta     Max Write Delta
Test     2.4.x     2.6.x    2.4.x     2.6.x
X11       0.10      0.16     0.05      0.65
/proc     0.07      0.17     0.05      0.65
net out   0.15      0.19     0.05      0.75
net in    0.17      0.23     0.05      0.95
dsk wrt   0.49      0.18     0.25      1.05
dsk copy  2.48      0.68     2.25      1.25
disk rd   3.03      1.61     2.75      1.35

LONG DELAYS
===========

Note I still see over 110% worst case overhead on a max priority real time
CPU task (no system calls) when doing heavy disk I/O on 2.6. It is much
better than 2.4, but still disturbing. What I would hope would happen on a
dual CPU system like mine, is that the real time task tends to be on one
CPU and the other system activity would tend to stay on the other CPU.
However, the results do not seem to indicate that behavior.

VARYING SYSTEM CALL TIMES
=========================

In 2.4, it appears that the duration of the write system call is basically
fixed and dependent on the duration of the audio fragment. In 2.6, this
behavior is now different. If I look at the chart in detail, it appears the
system is queueing up several write operations during the first few seconds
of testing. You can see this by consistently low elapsed times for the
write system call. Then the elapsed time for the write bounces up / down in
a sawtooth pattern over a 1 msec range. Could someone explain the cause of
this new behavior and if there is a setting to restore the old behavior? I
am concerned that this queueing adds latency to audio operations (when
trying to synchronize audio with other real time behavior).

LONG NETWORK LATENCIES
======================

In about 25 minutes of heavy testing, I had two latency traces with
/proc/sys/kernel/preempt_max_latency set to 700. They had the same start /
end location with the long delay as follows:
  730 us, entries: 361
  ...
  started at rtl8139_poll+0x3c/0x160
  ended at   rtl8139_poll+0x100/0x160
  00000001 0.000ms (+0.000ms): rtl8139_poll (net_rx_action)
  00000001 0.140ms (+0.140ms): rtl8139_rx (rtl8139_poll)
  00000001 0.556ms (+0.416ms): alloc_skb (rtl8139_rx)
  ... remaining items all > +0.005ms ...

  731 us, entries: 360
  ...
  started at rtl8139_poll+0x3c/0x160
  ended at   rtl8139_poll+0x100/0x160
  00000001 0.000ms (+0.000ms): rtl8139_poll (net_rx_action)
  00000001 0.000ms (+0.000ms): rtl8139_rx (rtl8139_poll)
  00000001 0.002ms (+0.001ms): alloc_skb (rtl8139_rx)
  00000001 0.141ms (+0.139ms): kmem_cache_alloc (alloc_skb)
  00000001 0.211ms (+0.070ms): __kmalloc (alloc_skb)
  00000001 0.496ms (+0.284ms): eth_type_trans (rtl8139_rx)
  00000001 0.565ms (+0.068ms): netif_receive_skb (rtl8139_rx)
  ... remaining items all > +0.005ms ...

Still much better than my previous results (before setting
netdev_max_backlog).

I will be running some additional tests
 - reducing preempt_max_latency
 - running with sortirq and hardirq_preemption=0
to see if these uncover any further problems.

Thanks again for the good work.
--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>