public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: "Zhu, Lipeng" <lipeng.zhu@intel.com>
Cc: tkoenig@netcologne.de, rep.dot.nop@gmail.com,
	fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org,
	hongjiu.lu@intel.com, tianyou.li@intel.com, pan.deng@intel.com,
	wangyang.guo@intel.com, Zhu@imap.gmail.com
Subject: Re: [PATCH v6] libgfortran: Replace mutex with rwlock
Date: Fri, 8 Dec 2023 11:19:31 +0100	[thread overview]
Message-ID: <ZXLts4DB4ipgNdth@tucnak> (raw)
In-Reply-To: <20230818031818.2161842-1-lipeng.zhu@intel.com>

On Fri, Aug 18, 2023 at 11:18:19AM +0800, Zhu, Lipeng wrote:
> From: Lipeng Zhu <lipeng.zhu@intel.com>
> 
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit function is around 30%, in most instances,
> we can get the unit in the phase of reading the unit_cache or unit_root
> tree. So split the read/write phase by rwlock would be an approach to
> make it more parallel.
> 
> BTW, the IPC metrics can gain around 9x in our test
> server with 220 cores. The benchmark we used is
> https://github.com/rwesson/NEAT
> 
> libgcc/ChangeLog:
> 
>     * gthr-posix.h (__GTHREAD_RWLOCK_INIT): New macro
>     (__gthrw): New function
>     (__gthread_rwlock_rdlock): New function
>     (__gthread_rwlock_tryrdlock): New function
>     (__gthread_rwlock_wrlock): New function
>     (__gthread_rwlock_trywrlock): New function
>     (__gthread_rwlock_unlock): New function
> 
> libgfortran/ChangeLog:
> 
>     * io/async.c (DEBUG_LINE): New
>     * io/async.h (RWLOCK_DEBUG_ADD): New macro
>     (CHECK_RDLOCK): New macro
>     (CHECK_WRLOCK): New macro
>     (TAIL_RWLOCK_DEBUG_QUEUE): New macro
>     (IN_RWLOCK_DEBUG_QUEUE): New macro
>     (RDLOCK): New macro
>     (WRLOCK): New macro
>     (RWUNLOCK): New macro
>     (RD_TO_WRLOCK): New macro
>     (INTERN_RDLOCK): New macro
>     (INTERN_WRLOCK): New macro
>     (INTERN_RWUNLOCK): New macro
>     * io/io.h (internal_proto): Define unit_rwlock
>     * io/transfer.c (st_read_done_worker): Relace unit_lock with unit_rwlock
>     (st_write_done_worker): Relace unit_lock with unit_rwlock
>     * io/unit.c (get_gfc_unit): Relace unit_lock with unit_rwlock
>     (if): Relace unit_lock with unit_rwlock
>     (close_unit_1): Relace unit_lock with unit_rwlock
>     (close_units): Relace unit_lock with unit_rwlock
>     (newunit_alloc): Relace unit_lock with unit_rwlock
>     * io/unix.c (flush_all_units): Relace unit_lock with unit_rwlock

The changeLog entries are all incorrect.
1) they should be indented by a tab, not 4 spaces, and should end with
   a dot
2) when several consecutive descriptions have the same text, especially
   when it is long, it should use Likewise. for the 2nd and following
3) (internal_proto) is certainly not what you've changed, from what I can
   see in io.h you've done:
	* io/io.h (struct gfc_unit): Change UNIT_LOCK to UNIT_RWLOCK in
	a comment.
	(unit_lock): Remove including associated internal_proto.
	(unit_rwlock): New declarations including associated internal_proto.
	(dec_waiting_unlocked): Use WRLOCK and RWUNLOCK on unit_rwlock
	instead of __gthread_mutex_lock and __gthread_mutex_unlock on
	unit_lock.
   (if) is certainly not what you've changed either, always find what
   function or macro the change was in, or if you remove something, state
   it, if you add something, state it.
4) all the
   Replace unit_lock with unit_rwlock. descriptions only partially match
   reality, you've also changed the operations on those variables.

> --- a/libgfortran/io/async.h
> +++ b/libgfortran/io/async.h
> @@ -207,9 +207,132 @@
>      INTERN_LOCK (&debug_queue_lock);					\
>      MUTEX_DEBUG_ADD (mutex);						\
>      INTERN_UNLOCK (&debug_queue_lock);					\
> -    DEBUG_PRINTF ("%s" DEBUG_RED "ACQ:" DEBUG_NORM " %-30s %78p\n", aio_prefix, #mutex, mutex); \
> +    DEBUG_PRINTF ("%s" DEBUG_RED "ACQ:" DEBUG_NORM " %-30s %78p\n", aio_prefix, #mutex, \
> +		 mutex); \

Why are you changing this at all?

> +#define RD_TO_WRLOCK(rwlock) \
> +  RWUNLOCK (rwlock);\

At least a space before \ (or better tab

> +#define RD_TO_WRLOCK(rwlock) \
> +  RWUNLOCK (rwlock);\

Likewise.

> +  WRLOCK (rwlock);
> +#endif
> +#endif
> +
> +#ifndef __GTHREAD_RWLOCK_INIT
> +#define RDLOCK(rwlock) LOCK (rwlock)
> +#define WRLOCK(rwlock) LOCK (rwlock)
> +#define RWUNLOCK(rwlock) UNLOCK (rwlock)
> +#define RD_TO_WRLOCK(rwlock) {}

do {} while (0)
instead of {}
?

>  #endif
>  
>  #define INTERN_LOCK(mutex) T_ERROR (__gthread_mutex_lock, mutex);
>  
>  #define INTERN_UNLOCK(mutex) T_ERROR (__gthread_mutex_unlock, mutex);
>  
> +#define INTERN_RDLOCK(rwlock) T_ERROR (__gthread_rwlock_rdlock, rwlock);
> +#define INTERN_WRLOCK(rwlock) T_ERROR (__gthread_rwlock_wrlock, rwlock);
> +#define INTERN_RWUNLOCK(rwlock) T_ERROR (__gthread_rwlock_unlock, rwlock);

Admittedly preexisting issue, but I wonder why the ; at the end, all the
uses of RDLOCK etc. I've seen were followed by ;

> --- a/libgfortran/io/unit.c
> +++ b/libgfortran/io/unit.c
> @@ -33,34 +33,36 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>  
>  
>  /* IO locking rules:
> -   UNIT_LOCK is a master lock, protecting UNIT_ROOT tree and UNIT_CACHE.
> +   UNIT_RWLOCK is a master lock, protecting UNIT_ROOT tree and UNIT_CACHE.

master rw lock
?

> +/* get_gfc_unit_from_root()-- Given an integer, return a pointer
> +  to the unit structure. Returns NULL if the unit does not exist,
> +   otherwise returns a locked unit. */

Formatting, to is indented differently from otherwise, both should
be 3 spaces, and there should be 2 spaces after ., rather than just
one (in both spots).

> +
> +static inline gfc_unit * get_gfc_unit_from_unit_root (int n)

Formatting, there shouldn't be space after *, but also function
name should be at the beginning of line, so in this case it should
be
static inline gfc_unit *
get_gfc_unit_from_unit_root (int n)

> +{
> +    gfc_unit *p;
> +    int c = 0;
> +    p = unit_root;

This should be indented by 2 spaces rather than 4.

> +  while (p != NULL)
> +    {
> +      c = compare (n, p->unit_number);
> +      if (c < 0)
> +	p = p->left;
> +      if (c > 0)
> +	p = p->right;
> +      if (c == 0)
> +	break;
> +    }
> +    return p;

And the above return p; line as well.

	Jakub


  reply	other threads:[~2023-12-08 10:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  2:32 [PATCH v4] " Zhu, Lipeng
2023-05-16  7:08 ` Zhu, Lipeng
2023-05-23  2:53   ` Zhu, Lipeng
2023-05-24 19:18     ` Thomas Koenig
2023-08-18  3:06       ` Zhu, Lipeng
2023-09-14  8:33         ` Zhu, Lipeng
2023-10-23  1:21           ` Zhu, Lipeng
2023-10-23  5:52             ` Thomas Koenig
2023-10-23 23:59               ` Zhu, Lipeng
2023-11-01 10:14                 ` Zhu, Lipeng
2023-11-02  9:58                   ` Bernhard Reutner-Fischer
2023-11-23  9:36                     ` Zhu, Lipeng
2023-12-07  5:18                       ` Zhu, Lipeng
2023-08-18  3:18       ` [PATCH v6] " Zhu, Lipeng
2023-12-08 10:19         ` Jakub Jelinek [this message]
2023-12-09 15:13           ` Zhu, Lipeng
2023-12-09 15:39             ` [PATCH v7] " Lipeng Zhu
2023-12-09 15:23               ` Jakub Jelinek
2023-12-10  3:25                 ` Zhu, Lipeng
2023-12-11 17:45                   ` H.J. Lu
2023-12-12  2:05                     ` Zhu, Lipeng
2023-12-13 20:52                       ` Thomas Schwinge
2023-12-14  2:28                         ` Zhu, Lipeng
2023-12-14 12:29                           ` Thomas Schwinge
2023-12-14 12:39                             ` Jakub Jelinek
2023-12-15  5:43                               ` Zhu, Lipeng
2023-12-21 11:42                         ` Thomas Schwinge
2023-12-22  6:48                           ` Lipeng Zhu
2024-01-03  9:14                           ` Lipeng Zhu
2024-01-17 13:25                             ` Lipeng Zhu
2023-12-14 15:50               ` Richard Earnshaw (lists)
2023-12-15 11:31                 ` Lipeng Zhu
2023-12-15 19:23                   ` Richard Earnshaw
2024-01-02 11:57                     ` Vaseeharan Vinayagamoorthy
2024-01-03  1:02                       ` Lipeng Zhu

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=ZXLts4DB4ipgNdth@tucnak \
    --to=jakub@redhat.com \
    --cc=Zhu@imap.gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongjiu.lu@intel.com \
    --cc=lipeng.zhu@intel.com \
    --cc=pan.deng@intel.com \
    --cc=rep.dot.nop@gmail.com \
    --cc=tianyou.li@intel.com \
    --cc=tkoenig@netcologne.de \
    --cc=wangyang.guo@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).