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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux