tech-kern archive

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

Re: uvm_object::vmobjlock

Antti Kantee <> wrote:
> <...> 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".

Agree, hence this thread.

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

Heh?  The mutex object pool has a necessary alignment and padding, which
guarantees that the lock has its own cache line.  That was one of the
reasons, besides reference counting, why lock object pool was invented.

Can you explain "'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.

It is not a primary reason for the change, rather a side effect.  However,
avoiding potential false-sharing on obj locks is a reasonable target too.


Home | Main Index | Thread Index | Old Index