From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268669AbUHTS6f (ORCPT ); Fri, 20 Aug 2004 14:58:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266914AbUHTS6e (ORCPT ); Fri, 20 Aug 2004 14:58:34 -0400 Received: from mx2.elte.hu ([157.181.151.9]:54956 "EHLO mx2.elte.hu") by vger.kernel.org with ESMTP id S266003AbUHTSzT (ORCPT ); Fri, 20 Aug 2004 14:55:19 -0400 Date: Fri, 20 Aug 2004 20:56:33 +0200 From: Ingo Molnar To: "K.R. Foley" Cc: linux-kernel@vger.kernel.org, Thomas Charbonnel , Florian Schmidt , Felipe Alfaro Solana , Lee Revell , Mark_H_Johnson@raytheon.com Subject: Re: [patch] voluntary-preempt-2.6.8.1-P5 Message-ID: <20040820185633.GE21956@elte.hu> References: <1092628493.810.3.camel@krustophenia.net> <20040816040515.GA13665@elte.hu> <1092654819.5057.18.camel@localhost> <20040816113131.GA30527@elte.hu> <20040816120933.GA4211@elte.hu> <1092716644.876.1.camel@krustophenia.net> <20040817080512.GA1649@elte.hu> <20040819073247.GA1798@elte.hu> <20040820133031.GA13105@elte.hu> <41264506.1090302@cybsft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41264506.1090302@cybsft.com> 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 * K.R. Foley wrote: > Here is a latency trace generated by the NFS compile in the > stress-kernel. It is ~1.7 ms which doesn't really surprise me for the > NFS compile. I am going to take the NFS compile out of the test now > and see what else falls out. NFS uses lock_kernel() for most of its locking. This means that the sharing and locking rules and assumptions are not clear (it's all within this opaque lock). I tried to figure out whether it would be safe to do a lock-break in nfs_cached_lookup() but it's quite hard ... Please bug the NFS-client maintainer(s) about this. To break this latency we'd have to do a lock-break in fs/nfs/dir.c:nfs_cached_lookup()'s main loop: for(;(page = find_get_page(dir->i_mapping, desc.page_index)); desc.page_index++) { res = -EIO; you could try this at the end of the loop: if (res == 0) goto out_found; if (res != -EAGAIN) break; + cond_resched(); } but i cannot guarantee that this is correct ... It might seem to work now but break later under load, etc. It's the NFS maintainer's call. > If it would be useful for me to provide additional information with > this, please let me know. reports like this are perfect for most latencies. I tried to include everything that is needed normally in /proc/latency_trace itself. Ingo