All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Tejun Heo <htejun@gmail.com>
Cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH linux-2.6 01/04] brsem: implement big reader semaphore
Date: Sun, 25 Sep 2005 21:22:47 +1000	[thread overview]
Message-ID: <43368887.2020008@yahoo.com.au> (raw)
In-Reply-To: <43367676.1080308@gmail.com>

Tejun Heo wrote:

>  I did a busy-loop microbenchmark, and I think it's informative enough. :-)
> 

Great!

>  The following command is run on three versions - vanilla version, one 
> with read_down/up(->s_umount) added to vfs_write(), and one with 
> brsem_read_down/up(->s_umount) added to vfs_write().
> 
> # time -p dd if=/dev/zero of=out bs=32 count=10M
> 
>  The test is run three times and the results are averaged.
> 
> a. vanilla
> 
> real 58.63
> user 5.61
> sys 52.37
> 
> b. rwsem
> 
> real 59.24
> user 6.06
> sys 52.29
> 
> c. brsem
> 
> real 61.74
> user 5.78
> sys 55.04
> 
>  I don't think brsem has any chance of being faster than rwsem if it's 
> slower in this micro benchmark.  One weird thing is that the result of 
> rwsem consistently showed higher user time and lower system time than 
> vanilla (no synchronization) case, maybe oprofiling will tell something.
> 

Yep, probably just some timing or cache anomaly, generally just
sum the user and system time in the case where you are running
identical userspace code... I wouldn't worry too much about it.

>  Anyways, you were absolutely right.  My brsem was a pretty stupid idea 
> after all.  Let's hope at least I learned something from it.  :-(
> 

I wouldn't say stupid. Implementation was too complex, but some
clever ideas were required to solve the problems you identified.

There are definitely a couple of possible places where a brsem
may be useful, and I think cpucontrol semaphore is one of those.

Al can probably comment on its use in the superblock. It seems
fair enough, though I think we'll want to slim down my naive
rwsem array and maybe think about using alloc_percpu.

Is the remount case much rarer than mount/unmount? Do we need to
be careful about bloating the size of the superblock on large
machines? In that case maybe a global remount brsem will be
enough to handle this race?

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2005-09-25 11:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-25  6:43 [PATCH linux-2.6 00/04] brsem: [RFC] big reader semaphore Tejun Heo
2005-09-25  6:43 ` [PATCH linux-2.6 01/04] brsem: implement " Tejun Heo
2005-09-25  7:19   ` Nick Piggin
2005-09-25  8:03     ` Nick Piggin
2005-09-25  8:11     ` Tejun Heo
2005-09-25  8:27       ` Nick Piggin
2005-09-25  8:53         ` Tejun Heo
2005-09-25  9:24           ` Nick Piggin
2005-09-25 10:05             ` Tejun Heo
2005-09-25 11:22               ` Nick Piggin [this message]
2005-09-25  6:43 ` [PATCH linux-2.6 02/04] brsem: convert super_block->s_umount to brsem Tejun Heo
2005-09-25  6:43 ` [PATCH linux-2.6 03/04] brsem: fix ro-remount <-> open race condition Tejun Heo
2005-09-25  6:43 ` [PATCH linux-2.6 04/04] brsem: convert cpucontrol to brsem Tejun Heo
2005-09-25  7:39   ` Nick Piggin
2005-09-25  8:03     ` Tejun Heo
2005-09-25 23:46     ` Nathan Lynch
2005-09-26  1:11       ` Nick Piggin
2005-09-26  4:05         ` Tejun Heo

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=43368887.2020008@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=htejun@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.