Re: uvm_object::vmobjlock

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Thu Jan 28 2010 at 23:08:07 +0000, Mindaugas Rasiukevicius wrote:
> > 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).

Ok.  I don't have those cases cached enough in my head to be able to say
this or that without suggesting a paint color, but sounds intuitively
useful.  Given the gruesome size of the rototill, I think you'll agree
it's important for everyone to have a clear idea about the implications
beforehand beyond "it'll be better".

> > 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.

I wrote "for example" for a reason -- vnodes are a major consumer of uvm
objects.  I didn't even look at the rest, but wouldn't be too surprised
with similar results, given that the uvm object itself was most of the
quoted size.

If you are talking about memory not within the object, well, then "all
bets are off" applies.  I might argue equally handwavily that you'll
cause false sharing with other locks from the mutex obj pool, and even
for many many more locks, since you don't even get the "protection" of
the data after the lock being "safe".  So this is a very unconvincing
rationale for the change for me and actually I'd handwave it to be a
reason *against* it.

However, it doesn't matter as long as (1) applies.