Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 19 Dec 2002 17:17:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 19 Dec 2002 17:17:00 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:5129 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Thu, 19 Dec 2002 17:16:17 -0500 Date: Thu, 19 Dec 2002 14:22:12 -0800 (PST) From: Linus Torvalds To: Jamie Lokier cc: bart@etpmod.phys.tue.nl, , , , , , , , Subject: Re: Intel P6 vs P7 system call performance In-Reply-To: <20021219221043.GA18562@bjl1.asuk.net> 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: 1269 Lines: 36 On Thu, 19 Dec 2002, Jamie Lokier wrote: > Linus Torvalds wrote: > > For _zero_ gain. The jump to the library address has to be indirect > > anyway, and glibc has several places to put the information without any > > mmap's or anything like that. > > This is not true, (but your overall point is still correct). Go back and read the postings by Uli. Uli's suggested glibc approach is to just put the magis system call address (which glibc gets from the AT_SYSINFO elf aux table entry) into the per-thread TLS area, which is alway spointed to by %gs anyway. THIS WORKS WITH ALL DSO'S WITHOUT ANY GAMES, ANY MMAP'S, ANY RELINKING, OR ANY EXTRA WORK AT ALL! The system call entry becomes a simple call *%gs:constant-offset Not mmap. No magic system calls. No relinking. Not _nothing_. One instruction, that's it. See for example Uli's posting in this thread from the day before yesterday, message ID <3DFF6D4B.3060107@redhat.com>. So please stop arguing about any extra work, because none is needed. 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/