From: Arnd Bergmann <arnd@arndb.de>
To: Jared Hulbert <jaredeh@gmail.com>
Cc: Linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
linux-mtd <linux-mtd@lists.infradead.org>,
"Jörn Engel" <joern@logfs.org>,
tim.bird@am.sony.com, cotte@de.ibm.com, nickpiggin@yahoo.com.au
Subject: Re: [PATCH 04/10] AXFS: axfs_inode.c
Date: Thu, 21 Aug 2008 17:12:26 +0200 [thread overview]
Message-ID: <200808211712.27146.arnd@arndb.de> (raw)
In-Reply-To: <6934efce0808210806r701f2e3bo677d2bd2da78faec@mail.gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> > Have you seen any benefit of the rwsem over a simple mutex? I would guess
> > that you can never even get into the situation where you get concurrent
> > readers since I haven't found a single down_read() in your code, only
> > downgrade_write()
>
> We implemented a rwsem here because you can get concurrent readers.
> My understanding is that downgrade_write() puts the rewem into the
> same state as down_read(). Â Am I mistaken?
Your interpretation of downgrade_write is correct, but if every thread
always does
down_write();
serialized_code();
downgrade_write();
parallel_code();
up_read();
Then you still won't have any concurrency, because each thread trying
to down_write() will be blocked until the previous one has done its up_read(),
causing parallel_code() to be serialized as well.
In addition to that, I'd still consider it better to use a simple mutex
if parallel_code() is a much faster operation than serialized_code(), as it
is in your case, where only the memcpy is parallel and that is much slower
than the deflate.
Arnd <><
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Jared Hulbert" <jaredeh@gmail.com>
Cc: cotte@de.ibm.com, linux-embedded@vger.kernel.org,
nickpiggin@yahoo.com.au, "Jörn Engel" <joern@logfs.org>,
Linux-kernel@vger.kernel.org,
linux-mtd <linux-mtd@lists.infradead.org>,
tim.bird@am.sony.com
Subject: Re: [PATCH 04/10] AXFS: axfs_inode.c
Date: Thu, 21 Aug 2008 17:12:26 +0200 [thread overview]
Message-ID: <200808211712.27146.arnd@arndb.de> (raw)
In-Reply-To: <6934efce0808210806r701f2e3bo677d2bd2da78faec@mail.gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> > Have you seen any benefit of the rwsem over a simple mutex? I would guess
> > that you can never even get into the situation where you get concurrent
> > readers since I haven't found a single down_read() in your code, only
> > downgrade_write()
>
> We implemented a rwsem here because you can get concurrent readers.
> My understanding is that downgrade_write() puts the rewem into the
> same state as down_read(). Am I mistaken?
Your interpretation of downgrade_write is correct, but if every thread
always does
down_write();
serialized_code();
downgrade_write();
parallel_code();
up_read();
Then you still won't have any concurrency, because each thread trying
to down_write() will be blocked until the previous one has done its up_read(),
causing parallel_code() to be serialized as well.
In addition to that, I'd still consider it better to use a simple mutex
if parallel_code() is a much faster operation than serialized_code(), as it
is in your case, where only the memcpy is parallel and that is much slower
than the deflate.
Arnd <><
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Jared Hulbert" <jaredeh@gmail.com>
Cc: Linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
linux-mtd <linux-mtd@lists.infradead.org>,
"Jörn Engel" <joern@logfs.org>,
tim.bird@am.sony.com, cotte@de.ibm.com, nickpiggin@yahoo.com.au
Subject: Re: [PATCH 04/10] AXFS: axfs_inode.c
Date: Thu, 21 Aug 2008 17:12:26 +0200 [thread overview]
Message-ID: <200808211712.27146.arnd@arndb.de> (raw)
In-Reply-To: <6934efce0808210806r701f2e3bo677d2bd2da78faec@mail.gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> > Have you seen any benefit of the rwsem over a simple mutex? I would guess
> > that you can never even get into the situation where you get concurrent
> > readers since I haven't found a single down_read() in your code, only
> > downgrade_write()
>
> We implemented a rwsem here because you can get concurrent readers.
> My understanding is that downgrade_write() puts the rewem into the
> same state as down_read(). Am I mistaken?
Your interpretation of downgrade_write is correct, but if every thread
always does
down_write();
serialized_code();
downgrade_write();
parallel_code();
up_read();
Then you still won't have any concurrency, because each thread trying
to down_write() will be blocked until the previous one has done its up_read(),
causing parallel_code() to be serialized as well.
In addition to that, I'd still consider it better to use a simple mutex
if parallel_code() is a much faster operation than serialized_code(), as it
is in your case, where only the memcpy is parallel and that is much slower
than the deflate.
Arnd <><
next prev parent reply other threads:[~2008-08-21 15:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-21 5:45 [PATCH 04/10] AXFS: axfs_inode.c Jared Hulbert
2008-08-21 5:45 ` Jared Hulbert
2008-08-21 8:35 ` Carsten Otte
2008-08-21 8:35 ` Carsten Otte
2008-08-21 11:35 ` Arnd Bergmann
2008-08-21 11:35 ` Arnd Bergmann
2008-08-21 12:17 ` Arnd Bergmann
2008-08-21 12:17 ` Arnd Bergmann
2008-08-21 12:17 ` Arnd Bergmann
2008-08-21 15:06 ` Jared Hulbert
2008-08-21 15:06 ` Jared Hulbert
2008-08-21 15:12 ` Arnd Bergmann [this message]
2008-08-21 15:12 ` Arnd Bergmann
2008-08-21 15:12 ` Arnd Bergmann
2008-08-22 2:22 ` Phillip Lougher
2008-08-22 2:22 ` Phillip Lougher
2008-08-22 3:23 ` Jared Hulbert
2008-08-22 3:23 ` Jared Hulbert
2008-08-22 3:29 ` Phillip Lougher
2008-08-22 3:29 ` Phillip Lougher
2008-08-22 10:00 ` Arnd Bergmann
2008-08-22 10:00 ` Arnd Bergmann
2008-08-22 17:08 ` Phillip Lougher
2008-08-22 17:08 ` Phillip Lougher
2008-08-22 17:19 ` Jörn Engel
2008-08-22 17:19 ` Jörn Engel
2008-08-22 17:19 ` Jörn Engel
2008-08-22 18:04 ` Jared Hulbert
2008-08-22 18:04 ` Jared Hulbert
2008-08-22 0:21 ` Phillip Lougher
2008-08-22 0:21 ` Phillip Lougher
2008-08-22 0:21 ` Phillip Lougher
2008-08-22 3:27 ` Jared Hulbert
2008-08-22 3:27 ` Jared Hulbert
2008-08-22 3:46 ` Phillip Lougher
2008-08-22 3:46 ` Phillip Lougher
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=200808211712.27146.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Linux-kernel@vger.kernel.org \
--cc=cotte@de.ibm.com \
--cc=jaredeh@gmail.com \
--cc=joern@logfs.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nickpiggin@yahoo.com.au \
--cc=tim.bird@am.sony.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.