From: "Zhu, Lipeng" <lipeng.zhu@intel.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: "tkoenig@netcologne.de" <tkoenig@netcologne.de>,
"rep.dot.nop@gmail.com" <rep.dot.nop@gmail.com>,
"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
"Lu, Hongjiu" <hongjiu.lu@intel.com>,
"Li, Tianyou" <tianyou.li@intel.com>,
"Deng, Pan" <pan.deng@intel.com>,
"Guo, Wangyang" <wangyang.guo@intel.com>
Subject: RE: [PATCH v6] libgfortran: Replace mutex with rwlock
Date: Sat, 9 Dec 2023 15:13:52 +0000 [thread overview]
Message-ID: <PH7PR11MB60564999862E21ADD4FE038A9F89A@PH7PR11MB6056.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ZXLts4DB4ipgNdth@tucnak>
On 2023/12/8 18:19, Jakub Jelinek wrote:
> 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.
>
Hi Jakub,
Thanks for your help, very appreciated! I just updated the patch according to
your comments. A new version [PATCH V7] is sent out for your review which
update the change log and formatting code according to your following
comments.
Lipeng Zhu
> > --- 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
next prev parent reply other threads:[~2023-12-09 15:13 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
2023-12-09 15:13 ` Zhu, Lipeng [this message]
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=PH7PR11MB60564999862E21ADD4FE038A9F89A@PH7PR11MB6056.namprd11.prod.outlook.com \
--to=lipeng.zhu@intel.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=hongjiu.lu@intel.com \
--cc=jakub@redhat.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).