public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Nathan Lynch <Nathan_Lynch@codesourcery.com>
To: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Cc: "GNU C. Library" <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2] Add x86 32 bit vDSO time function support
Date: Mon, 03 Nov 2014 23:51:00 -0000	[thread overview]
Message-ID: <54581516.9010908@codesourcery.com> (raw)
In-Reply-To: <5457E5D5.6000103@linux.vnet.ibm.com>

On 11/03/2014 02:30 PM, Adhemerval Zanella wrote:
> On 09-10-2014 17:50, Nathan Lynch wrote:
>> On 10/09/2014 01:31 PM, Adhemerval Zanella wrote:
>>
>>> +#ifdef SHARED
>>> +# define SYSCALL_GETTIME(id, tp) \
>>> +  ({ long int (*f) (clockid_t, struct timespec *) = __vdso_clock_gettime; \
>>> +  long int v_ret;							  \
>>> +  PTR_DEMANGLE (f);							  \
>>> +  v_ret = (*f) (id, tp);						  \
>>> +  if (INTERNAL_SYSCALL_ERROR_P (v_ret, )) {				  \
>>> +    __set_errno (INTERNAL_SYSCALL_ERRNO (v_ret, ));			  \
>>> +    v_ret = -1;								  \
>>> +  }									  \
>>> +  v_ret; })
>> Does introducing the dispatch through function pointer here cause a
>> measurable performance regression on i386 kernels which lack the VDSO?
>> If so, is that a concern?
>>
>> When I've tried this approach on ARM, it appears to do so (around 5%
>> slowdown).
> 
> Using a simple benchmark (in attachments) the difference in such scenarios is not
> as drastic as ARM it seems:
> 
> kernel: Linux birita 3.13.0-39
> CPU:    Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
> 
> EGLIBC 2.19-0ubuntu6.3: 1415.12 cycles
> GLIBC 2.20 master:      1421.66 cycles

OK.


>>> +# define INTERNAL_GETTIME(id, tp) \
>>> +  ({ long int (*f) (clockid_t, struct timespec *) = __vdso_clock_gettime; \
>>> +  PTR_DEMANGLE (f);							  \
>>> +  (*f) (id, tp); })
>>> +#endif
>> I'm probably missing something, but I am failing to see the need for an
>> INTERNAL_GETTIME definition in
>> sysdeps/unix/sysv/linux/x86/clock_gettime.c.  I know this patch is
>> merely moving existing code, but sysdeps/unix/sysv/linux/clock_gettime.c
>> does not use INTERNAL_GETTIME, and neither does
>> sysdeps/unix/clock_gettime.c.
>>
>> INTERNAL_GETTIME is needed for timespec_get, but I am not seeing the
>> need to duplicate it for clock_gettime.
> 
> i386 does not define HAVE_CLOCK_GETTIME_VSYSCALL and thus:
> 
> sysdeps/unix/sysv/linux/clock_gettime.c:
> 
>  26: # define INTERNAL_VSYSCALL INTERNAL_SYSCALL
> 
> and then if INTERNAL_GETTIME is not defined, it will as:
> 
>  37 #ifndef INTERNAL_GETTIME
>  38 # define INTERNAL_GETTIME(id, tp) \
>  39   INTERNAL_VSYSCALL (clock_gettime, err, 2, id, tp)
>  40 #endif
> 
> And without proper set the PTR_DEMANGLE is not called either.

I think my point might be better expressed as: why is INTERNAL_GETTIME
defined in linux/clock_gettime.c at all?  It is not used in the
clock_gettime implementation.

The only use in glibc of a macro by that name is in
linux/timespec_get.c, and the arch can override it in its own
timespec_get.c (as x86_64 currently does).


> With PREPARE_VERSION_KNOWN fixes, is it ok to commit?

I have no objection, FWIW.

  parent reply	other threads:[~2014-11-03 23:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09 18:31 Adhemerval Zanella
2014-10-09 20:50 ` Nathan Lynch
2014-11-03 20:30   ` Adhemerval Zanella
2014-11-03 21:42     ` Adhemerval Zanella
2014-11-03 23:51     ` Nathan Lynch [this message]
2014-11-05 12:51       ` Adhemerval Zanella
2014-11-05 16:22         ` Nathan Lynch
2014-11-14 19:19           ` Adhemerval Zanella
2014-11-27 17:38             ` Adhemerval Zanella
  -- strict thread matches above, loose matches on Subject: below --
2014-11-19  7:53 Stefani Seibold
2014-06-27 21:21 Adhemerval Zanella
2014-06-27 21:58 ` Roland McGrath
2014-06-29 15:57   ` Adhemerval Zanella
2014-07-07 18:01     ` Adhemerval Zanella
2014-07-09 20:02     ` Roland McGrath
2014-07-10 14:33       ` Adhemerval Zanella
2014-07-22 17:32         ` Adhemerval Zanella
2014-07-23  0:40           ` Allan McRae
2014-07-23 13:56             ` Adhemerval Zanella
2014-09-10 14:20               ` Adhemerval Zanella
2014-09-22 15:01                 ` Adhemerval Zanella
2014-10-07  6:57             ` Stefani Seibold
2014-10-08 21:56               ` Roland McGrath
2014-10-08 22:02                 ` Adhemerval Zanella
2014-10-08 22:15                   ` Roland McGrath
2014-10-08 22:31                     ` Adhemerval Zanella
2014-08-02 16:48         ` Mike Frysinger

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=54581516.9010908@codesourcery.com \
    --to=nathan_lynch@codesourcery.com \
    --cc=azanella@linux.vnet.ibm.com \
    --cc=libc-alpha@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).