Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262272AbUKDPV4 (ORCPT ); Thu, 4 Nov 2004 10:21:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262266AbUKDPTu (ORCPT ); Thu, 4 Nov 2004 10:19:50 -0500 Received: from mx2.elte.hu ([157.181.151.9]:28890 "EHLO mx2.elte.hu") by vger.kernel.org with ESMTP id S262255AbUKDPSx (ORCPT ); Thu, 4 Nov 2004 10:18:53 -0500 Date: Thu, 4 Nov 2004 16:19:48 +0100 From: Ingo Molnar To: Mark_H_Johnson@raytheon.com Cc: Karsten Wiese , Bill Huey , Adam Heath , "K.R. Foley" , linux-kernel@vger.kernel.org, Florian Schmidt , Fernando Pablo Lopez-Lezcano , Lee Revell , Rui Nuno Capela , Thomas Gleixner , Michal Schmidt Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Message-ID: <20041104151948.GA25326@elte.hu> References: <20041104151631.GA24056@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041104151631.GA24056@elte.hu> User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-2.201, required 5.9, BAYES_00 -4.90, SORTED_RECIPS 2.70 X-ELTE-SpamLevel: X-ELTE-SpamScore: -2 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1307 Lines: 29 * Ingo Molnar wrote: > icmp/ping replies are handled by ksoftirqd. Once a networking request > has been handed to ksoftirqd it cannot be redirected to another CPU, > because softirq processing is fundamentally per-CPU. So if the network > interrupt hits the CPU where the RT-task is running then the RT task > will starve that ksoftirq instance (and hence the reply) even if > another CPU in the system is idle. > > i agree that this is an SMP/RT artifact that should be fixed. hardirq > workload can be redirected to other CPUs because it's single-threaded, > but it's not that easy for softirq workload. > > i suspect the same phenomenon causes some of the other scheduling > artifacts ('frozen' X) you've noticed. does the ping phenomenon go away if you chrt both the networking IRQ thread and both ksoftirqd's to above the RT task's priority? (this doesnt solve the problem though - that task has RT priority for a reason and on an SMP box the kernel should be able to schedule work without getting into this starvation scenario.) 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/