Re: [lvm-devel] Re: 2x Oracle slowdown from 2.2.16 to 2.4.4

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Jul 12, 2001 at 11:26:13AM +0200, Andi Kleen wrote:
> On Thu, Jul 12, 2001 at 04:30:46AM +0200, Andrea Arcangeli wrote:
> > I will soon somehow make those changes in the lvm (based on beta7) in my
> > tree and it will be interesting to see if this will make a difference. I
> > will also have a look to see if I can improve a little more the lvm_map
> > but other than those non rw semaphores there should be not a significant
					 ^ both
> > overhead to remove in the lvm fast path.
> 
> Even if you fix the snapshot_sem you still have the down on the _pe_lock 
> in lvm_map. The part covered by the PE lock is only a few tenths of cycles
> shorter than the part covered by the snapshot semaphore; so it is unlikely
> that you see much difference unless you change both to rwsems.

See the above 's', plural, in case it was not obious I meant "all the
semaphores in the fast path", not just one, of course doing just one
would been nearly useless.

Both semaphore_S_ are just converted to rwsem in 2.4.7pre6aa1 so the
fast path *cannot* block any longer in my current tree.

> Wouldn't a single semaphore be enough BTW to cover both? 

Actually the _pe_lock is global and it's hold for a short time so it
can make some sense. And if you look closely you'll see that _pe_lock
should _definitely_ be a rw_spinlock not a rw_semaphore. I didn't
changed that though just to keep the patch smaller and to avoid changing
the semantics of the lock, the only thing that matters for us is to
never block and to have a fast read fast path which is provided just
fine by the rwsem (i'll left the s/sem/spinlock/ to the CVS).

Andrea