public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* [PATCH v2 0/4] Move libio lock single-thread optimization to generic libc-lock
@ 2022-04-26 19:15 Adhemerval Zanella
  2022-04-26 19:15 ` [PATCH v2 1/4] libio: Assume _IO_MTSAFE_IO Adhemerval Zanella
                   ` (3 more replies)
  0 siblings, 4 replies; 23+ messages in thread
From: Adhemerval Zanella @ 2022-04-26 19:15 UTC (permalink / raw)
  To: libc-alpha, Florian Weimer

This patchset removes some old unused code (_IO_lock_inexpensive
and _IO_MTSAFE_IO), consolidate the stdio-lock.h and move the
single-thread lock optimization to generic code instead of
per-function usage.

Adhemerval Zanella (4):
  libio: Assume _IO_MTSAFE_IO
  Consolidate stdio-lock.h
  Move libio lock single-thread optimization to generic libc-lock (BZ
    #27842)
  Assume _LIBC and libc module for libc-lock.h

 Makeconfig                        |   2 -
 debug/Makefile                    |  43 +++++--------
 grp/Makefile                      |   4 +-
 gshadow/Makefile                  |   4 +-
 htl/Makefile                      |   2 -
 hurd/vpprintf.c                   |   4 --
 include/stdio.h                   |   2 +-
 libio/Makefile                    |   2 -
 libio/Versions                    |   3 -
 libio/clearerr.c                  |   4 --
 libio/feof.c                      |   7 ---
 libio/ferror.c                    |   6 --
 libio/fileno.c                    |   2 +-
 libio/fputc.c                     |   7 ---
 libio/genops.c                    |  66 -------------------
 libio/getc.c                      |   8 ---
 libio/getchar.c                   |   7 ---
 libio/iofdopen.c                  |   4 --
 libio/iofflush.c                  |   7 ---
 libio/iofgets.c                   |   7 ---
 libio/iofopen.c                   |   4 --
 libio/iofopncook.c                |   6 --
 libio/iofputs.c                   |   7 ---
 libio/iofread.c                   |   6 --
 libio/iofwrite.c                  |   6 +-
 libio/iopopen.c                   |  14 -----
 libio/ioungetc.c                  |   2 -
 libio/iovdprintf.c                |   2 -
 libio/iovsprintf.c                |   2 -
 libio/libio.h                     |  30 +++------
 libio/libioP.h                    |  30 ++-------
 libio/memstream.c                 |   7 ---
 libio/obprintf.c                  |   2 -
 libio/oldiofdopen.c               |   4 --
 libio/oldiofopen.c                |   4 --
 libio/oldiopopen.c                |  14 -----
 libio/oldstdfiles.c               |   6 --
 libio/putc.c                      |   7 ---
 libio/putchar.c                   |   5 --
 libio/stdfiles.c                  |  11 +---
 libio/vasprintf.c                 |   2 -
 libio/vsnprintf.c                 |   2 -
 libio/vswprintf.c                 |   2 -
 libio/wgenops.c                   |   2 -
 libio/wmemstream.c                |   7 ---
 nptl/Makefile                     |   3 -
 nptl/pthread_create.c             |   3 -
 pwd/Makefile                      |   1 -
 shadow/Makefile                   |   4 +-
 stdio-common/Makefile             |   2 -
 stdio-common/flockfile.c          |   1 -
 stdio-common/vfprintf-internal.c  |   4 --
 stdlib/Makefile                   |   9 ---
 stdlib/strfmon_l.c                |   2 -
 stdlib/strfrom-skeleton.c         |   2 -
 sysdeps/generic/stdio-lock.h      |  25 +++-----
 sysdeps/htl/stdio-lock.h          |  57 -----------------
 sysdeps/ieee754/float128/Makefile |   4 --
 sysdeps/mach/libc-lock.h          |  18 ++----
 sysdeps/nptl/libc-lock.h          |  74 ++++------------------
 sysdeps/nptl/stdio-lock.h         | 101 ------------------------------
 sysdeps/unix/sysv/linux/Makefile  |   1 -
 wcsmbs/Makefile                   |   2 -
 63 files changed, 65 insertions(+), 623 deletions(-)
 delete mode 100644 sysdeps/htl/stdio-lock.h
 delete mode 100644 sysdeps/nptl/stdio-lock.h

-- 
2.34.1


^ permalink raw reply	[flat|nested] 23+ messages in thread
* [PATCH v2 3/4] Move libio lock single-thread optimization to generic libc-lock (BZ #27842)
@ 2022-04-29 13:04 Wilco Dijkstra
  2022-04-29 17:13 ` Adhemerval Zanella
  0 siblings, 1 reply; 23+ messages in thread
From: Wilco Dijkstra @ 2022-04-29 13:04 UTC (permalink / raw)
  To: Adhemerval Zanella; +Cc: 'GNU C Library', Florian Weimer

Hi Adhemerval,

/* Lock the recursive named lock variable.  */
#define __libc_lock_lock_recursive(NAME) \
  do {                                                                        \
    void *self = THREAD_SELF;                                                 \
    if ((NAME).owner != self)                                                 \
      {									      \
	if (SINGLE_THREAD_P)                                                  \
	  (NAME).lock = 1;						      \
        else								      \
           lll_lock ((NAME).lock, LLL_PRIVATE);                               \
        (NAME).owner = self;                                                  \
      }                                                                       \
    ++(NAME).cnt;                                                             \
  } while (0)


The issue is that recursive locks are very expensive. Even with the single thread
optimization there are still 5 memory accesses just to take a free lock! While I'm in
favour of improving locks like above, I think removing the single threaded optimizations
from libio will cause major performance regressions in getc, putc, feof etc.

Basically doing single threaded optimizations at the highest level will always be faster
than doing it at the lock level. That doesn't mean optimizing general locks isn't useful,
however all it does is reduce the need to add single threaded optimizations rather than
make them completely unnecessary.

> Or if we are bounded to keep the current practice to check for single-thread and
> skip locks internally.  It would be good to consolidate all the internal lock
> usage and have the single-thread lock optimizations on all locks, not only on
> pthread_mutex_lock.

Yes, we should have single threaded optimization on all locks, including __libc_lock_lock.
Recursive locks can be optimized both for single threaded and multi-threaded case.
I'm wondering whether we could use the lock variable itself to store useful data (since most
ISAs will allow 64 bits). Then all you need to check is the .lock field and only if it is already
taken do the extra checks for ownership and incrementing recursion counter.

Cheers,
Wilco

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2022-05-16 16:23 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-26 19:15 [PATCH v2 0/4] Move libio lock single-thread optimization to generic libc-lock Adhemerval Zanella
2022-04-26 19:15 ` [PATCH v2 1/4] libio: Assume _IO_MTSAFE_IO Adhemerval Zanella
2022-04-27 12:34   ` Florian Weimer
2022-04-27 18:40     ` Adhemerval Zanella
2022-04-27 19:35       ` Adhemerval Zanella
2022-04-26 19:15 ` [PATCH v2 2/4] Consolidate stdio-lock.h Adhemerval Zanella
2022-04-27 13:25   ` Florian Weimer
2022-04-27 16:15     ` Adhemerval Zanella
2022-04-27 18:00       ` Florian Weimer
2022-04-27 18:35         ` Adhemerval Zanella
2022-04-27 18:44           ` Florian Weimer
2022-04-27 18:49             ` Adhemerval Zanella
2022-04-26 19:15 ` [PATCH v2 3/4] Move libio lock single-thread optimization to generic libc-lock (BZ #27842) Adhemerval Zanella
2022-04-27 13:30   ` Florian Weimer
2022-04-27 16:32     ` Adhemerval Zanella
2022-04-28 16:39       ` Adhemerval Zanella
2022-04-28 16:56         ` Florian Weimer
2022-04-28 17:14           ` Adhemerval Zanella
2022-04-26 19:15 ` [PATCH v2 4/4] Assume _LIBC and libc module for libc-lock.h Adhemerval Zanella
2022-04-29 13:04 [PATCH v2 3/4] Move libio lock single-thread optimization to generic libc-lock (BZ #27842) Wilco Dijkstra
2022-04-29 17:13 ` Adhemerval Zanella
2022-05-16 16:17   ` Wilco Dijkstra
2022-05-16 16:23     ` Florian Weimer

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).