Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 27 Aug 2002 15:12:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 27 Aug 2002 15:12:44 -0400 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:58629 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Tue, 27 Aug 2002 15:12:43 -0400 Date: Tue, 27 Aug 2002 12:22:59 -0700 (PDT) From: Linus Torvalds To: Hugh Dickins cc: Dave Jones , Marc Dietrich , Subject: Re: [PATCH] M386 flush_one_tlb invlpg In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1183 Lines: 34 On Tue, 27 Aug 2002, Hugh Dickins wrote: > > I just sent the 2.4.20-pre4 asm-i386/pgtable.h patch to Marcelo: > here's patch against 2.5.31 or current BK: please apply. This test is senseless, in my opinion: > + if (cpu_has_pge) \ > + __flush_tlb_single(addr); \ The test _should_ be for something like if (cpu_has_invlpg) __flush_tlb_single(addr); since we want to use the invlpg instruction regardless of any PGE issues if it is available. There's another issue, which is the fact that I do not believe that invlpg is even guaranteed to invalidate a G page at all - although obviously all current CPU's seem to work that way. However, I don't see that documented anywhere. It might make sense to mark the places that expect to invalidate a global page explicitly, and call that function "flush_one_global_rlb()" (even if it - at least for now - does the same thing as the regular single invalidate). Linus - 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/