Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 1 Jan 2002 06:13:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 1 Jan 2002 06:13:13 -0500 Received: from samba.sourceforge.net ([198.186.203.85]:56592 "HELO lists.samba.org") by vger.kernel.org with SMTP id ; Tue, 1 Jan 2002 06:12:57 -0500 Date: Tue, 1 Jan 2002 22:08:38 +1100 From: Anton Blanchard To: Alan Cox Cc: Andrew Morton , Manfred Spraul , Dave Jones , Linux Kernel Subject: Re: [patch] Prefetching file_read_actor() Message-ID: <20020101110838.GA11768@krispykreme> In-Reply-To: <3C30BC5F.227349E8@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Please bury such things in arch/cpu specific routines. Most non intel > processor hardware isnt that broken. Exactly, for example ppc32 and ppc64 implement the prefetch macros so we cant put intel specific prefetch hacks in generic code. The correct place to do it is in the copy_*_user routines where you can make decisions based on length etc. Davem already does this for sparc64 and Paulus is working on it for ppc32/64. I just grepped around for current prefetch usage and noticed we now use it in the list macros. Converting non struct list code (eg pagecache hash) to use for_each_list etc might give some benefits. Perhaps for_each_task could benefit from the same prefetching. Anton - 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/