Re: uvm_object::vmobjlock

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Antti Kantee <pooka%cs.hut.fi@localhost> wrote:
> > Unless anyone objects, I would like to change struct
> > uvm_object::vmobjlock to be dynamically allocated with mutex_obj_alloc
> > ().  It allows us to:  1) share the lock among objects by holding a
> > reference  2) avoid false-sharing on locks. Note that struct
> > vnode::v_interlock becomes a pointer, which means a chunk of mechanical
> > changes.
> 
> 1) can you give an example of where this is useful?  (i'm not saying it
>    isn't, i just don't like thinking ;)

Further locking improvements:

http://mail-index.netbsd.org/tech-kern/2009/01/11/msg003986.html

Another possible use, which was suggested by yamt@, is to improve locking in
UVM loaning (see XXX "livelock" marks in sys/uvm, e.g. uvm_anon_lockloanpg)
by holding a reference on the vmobjlock lock (right now, we lock page-queues,
since that prevents from page ownership drop i.e. dying of uvm_object).

> 2) really?  looks like for example for vnodes the next 64 bytes starting
>    from the interlock (on i386) require taking the interlock anyway.

The lock is in uvm_object, so it does not matter whether it is for vnodes
or whatever else.  Now the point - while next 64 bytes (in uvm_object!) may
require holding of lock, it does not prevent from false-sharing if the whole
object is not aligned.  At very least - ubc_object, vnode_cache, pmap_cache
need that.

-- 
Mindaugas