Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269357AbUIIG0j (ORCPT ); Thu, 9 Sep 2004 02:26:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269358AbUIIG0j (ORCPT ); Thu, 9 Sep 2004 02:26:39 -0400 Received: from mx1.elte.hu ([157.181.1.137]:61827 "EHLO mx1.elte.hu") by vger.kernel.org with ESMTP id S269357AbUIIG0g (ORCPT ); Thu, 9 Sep 2004 02:26:36 -0400 Date: Thu, 9 Sep 2004 08:27:38 +0200 From: Ingo Molnar To: Mark_H_Johnson@raytheon.com Cc: Lee Revell , Free Ekanayaka , Eric St-Laurent , linux-kernel , "K.R. Foley" , Felipe Alfaro Solana , Daniel Schmitt , "P.O. Gaillard" , nando@ccrma.stanford.edu, luke@audioslack.com, free78@tin.it Subject: Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-R1 Message-ID: <20040909062738.GI1362@elte.hu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1965 Lines: 63 * Mark_H_Johnson@raytheon.com wrote: > Not quite sure where to add touch_preempt_timing() calls - somewhere in the > loop in ide_outsl and ide_insl? [so we keep resetting the start /end > times?] > 00000001 0.002ms (+0.000ms): ata_output_data (taskfile_output_data) > 00000001 0.003ms (+0.542ms): ide_outsl (ata_output_data) > 00000001 0.545ms (+0.000ms): kunmap_atomic (ide_multwrite) yeah, i'd add it to ide_outsl. Something like the patch below. (it compiles but is untested otherwise.) another possibility besides DMA starvation is starvation between CPUs. The only way to exclude DMA as a source of CPU starvation would be to try a maxcpus=1 test using the SMP kernel. You dont even have to run the RT-latency tester for this - just the disk read/write workload should trigger the latency traces! Ingo --- linux/drivers/ide/ide-iops.c.orig +++ linux/drivers/ide/ide-iops.c @@ -56,7 +56,15 @@ static u32 ide_inl (unsigned long port) static void ide_insl (unsigned long port, void *addr, u32 count) { - insl(port, addr, count); + unsigned int chunk, offset = 0; + + while (count) { + chunk = min(128U, count); + insl(port, addr + offset, chunk); + count -= chunk; + offset += chunk; + touch_preempt_timing(); + } } static void ide_outb (u8 val, unsigned long port) @@ -86,7 +94,15 @@ static void ide_outl (u32 val, unsigned static void ide_outsl (unsigned long port, void *addr, u32 count) { - outsl(port, addr, count); + unsigned int chunk, offset = 0; + + while (count) { + chunk = min(128U, count); + outsl(port, addr + offset, chunk); + count -= chunk; + offset += chunk; + touch_preempt_timing(); + } } void default_hwif_iops (ide_hwif_t *hwif) - 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/