Messages in this thread | | | Date | Thu, 9 Feb 2012 11:40:22 +0200 | Subject | Re: [RFC][PATCH v1 5/9] ima: allocating iint improvements | From | "Kasatkin, Dmitry" <> |
| |
On Wed, Feb 1, 2012 at 8:46 PM, Kasatkin, Dmitry <dmitry.kasatkin@intel.com> wrote: > On Wed, Feb 1, 2012 at 6:58 PM, Eric Paris <eparis@parisplace.org> wrote: >> On Mon, Jan 30, 2012 at 5:14 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote: >>> From: Dmitry Kasatkin <dmitry.kasatkin@intel.com> >>> >> >>> static struct rb_root integrity_iint_tree = RB_ROOT; >>> -static DEFINE_SPINLOCK(integrity_iint_lock); >>> +static DEFINE_RWLOCK(integrity_iint_lock); >>> static struct kmem_cache *iint_cache __read_mostly; >> >> Has any profiling been done here? rwlocks have been shown to >> actually be slower on multi processor systems in a number of cases due >> to the cache line bouncing required. I believe the current kernel >> logic is that if you have a short critical section and you can't show >> profile data the rwlocks are better, just stick with a spinlock. > > No, I have not done any profiling. > My assumption was that rwlocks are better when there many readers. > If what you say is true then rwlocks are useless... > With big sections it is necessary to use rw semaphores. >
Hello,
I and Mimi made performance measurements with rwlocks and spinlocks. We used kernel compilation with multiple jobs as a test, because it reads and creates lots of files..
In all cases rwlocks implementation performed better than spinlocks, but very insignificantly. For example with total compilation time around 6 minutes, with rwlocks time was 1 - 3 seconds shorter... But always like that.
So as conclusion I can make, that usage of rwlocks is justified...
Thanks for bringing this up...
> - Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |