Re: [PATCH linux-2.6 01/04] brsem: implement big reader semaphore

[Nick Piggin <nickpiggin@yahoo.com.au>]

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 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/