Messages in this thread | | | Date | Mon, 20 Oct 2008 16:14:15 -0400 (EDT) | From | Mikulas Patocka <> | Subject | Re: RFC: one-bit mutexes (was: Re: [PATCH 2/3] Memory management livelock) |
| |
> > If you are concerned about the size of an inode, I can convert other > > mutexes to bit mutexes: i_mutex and inotify_mutex. > > I wouldn't worry for now. mutexes can be unlocked much faster than bit > mutexes, especially in the fastpath. And due to slab, it would be > unlikely to actually save any space.
Maybe inotify_mutex. You are right that i_mutex is so heavily contended that slowing it down to save few words wouldn't be good. Do you know about any inotify-intensive workload?
> > I could also create > > bit_spinlock (one-bit spinlock that uses test_and_set_bit) and save space > > for address_space->tree_lock, address_space->i_mmap_lock, > > address_space->private_lock, inode->i_lock. > > We have that already. It is much much faster to unlock spinlocks than > bit spinlocks in general (if you own the word exclusively, then it's > not, but then you would be less likely to save space), and we can also > do proper FIFO ticket locks with a larger word.
BTW. why do spinlocks on x86(64) have 32 bits and not 8 bits or 16 bits? Are atomic 32-bit instuctions faster?
Can x86(86) system have 256 CPUs?
Mikulas
| |