mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>,
	Ulrich Drepper <drepper@redhat.com>,
	Jamie Lokier <jamie@shareable.org>,
	"Martin J. Bligh" <mbligh@aracnet.com>,
	Wim Coekaerts <wim.coekaerts@oracle.com>,
	Joel Becker <Joel.Becker@oracle.com>,
	Chris McDermott <lcm@us.ibm.com>
Subject: Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)
Date: Thu, 4 Mar 2004 01:55:42 +0100	[thread overview]
Message-ID: <20040304005542.GZ4922@dualathlon.random> (raw)
In-Reply-To: <1078359248.10076.197.camel@cog.beaverton.ibm.com>

On Wed, Mar 03, 2004 at 04:14:08PM -0800, john stultz wrote:
> All,
> 	This patch implements the somewhat controversial vDSO hooks for
> vsyscall-gtod. This makes LD_PRELOADing or changes to glibc unnecessary,

the reason it's controversial is just because it's microslowing down
all syscalls to speedup gettimeofday, when you can avoid this kernel
change completely and implementing it zerocost like in x86-64. glibc
should simply call into the vsyscall directly. Why don't you simply
provide a patch against glibc, instead of proposing a patch against the
kernel? Of course this patch will depend on your vsyscall patch on the
kernel side, and that's fine. Another elf bitflag can be used to tell
glibc to use vgettimeofday or whatever, just like it happens with the
sysenter vsyscall.

This is just like the kernel patches people proposes when they get
vmalloc LDT allocation failure, because they run with the i686 glibc
instead of the only possibly supported i586 configuration. It makes no
sense to hide a glibc inefficiency in the kernel when you can fix it in
glibc and avoid the LDT 4k allocation completely since nobody will ever
call into pthread_create. It's not that wasting 4k of zone-normal per
task is a good thing, and wasting 64k of vmalloc per task is a bad
thing. they're both bad things, you just only can see the latter one
unless you're a kernel hacker, so people actually think the kmalloc LDT
thing is a bugfix, while it's just a bad band-aid (I mean, it's a good
thing at large, but not as the fix of the vmalloc LDT faliures).  I bet
if the LDT allocation was visible in /proc as easily as the manger
thread was visible with `ps` in linuxthreads, the LDT allocation would
been deferred to pthread_create too in the first place. As a matter of
fact I spent a few hours trying to fixup glibc some month ago, but the
flood of #ifdefs and the fact linuxthreads is dead made me desist and I
will try again with NTPL since it seems they didn't fix it (at least
last time I checked the code the LDT waste as still there).

  reply	other threads:[~2004-03-04  1:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-04  0:11 [RFC][PATCH] vsyscall-gtod_B3 (0/3) john stultz
2004-03-04  0:12 ` [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part1 (1/3) john stultz
2004-03-04  0:13   ` [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part2 (2/3) john stultz
2004-03-04  0:14     ` [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3) john stultz
2004-03-04  0:55       ` Andrea Arcangeli [this message]
2004-03-04  2:16         ` Ulrich Drepper
2004-03-04  2:43           ` john stultz
2004-03-04  3:14             ` Andrea Arcangeli
2004-03-04  8:09             ` Ulrich Drepper
2004-03-04 19:02               ` john stultz
2004-03-04  2:47           ` Andrea Arcangeli
2004-03-04  2:54             ` john stultz
2004-03-04  3:15               ` Andrea Arcangeli
2004-03-04  8:57               ` Jakub Jelinek
2004-03-04 16:45                 ` Andrea Arcangeli
2004-03-04  8:00         ` Jamie Lokier
2004-03-04  8:37           ` Jakub Jelinek
2004-03-04 17:48             ` Andrea Arcangeli
2004-03-04  0:15 ` [RFC] vsyscall-gtod_test_B3.tar.gz john stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040304005542.GZ4922@dualathlon.random \
    --to=andrea@suse.de \
    --cc=Joel.Becker@oracle.com \
    --cc=ak@suse.de \
    --cc=drepper@redhat.com \
    --cc=jamie@shareable.org \
    --cc=johnstul@us.ibm.com \
    --cc=lcm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=wim.coekaerts@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®