Quoting Chris Wright (chrisw@private):
...
> > + spin_unlock(&lsm_spinlock);
> > + e2 = kmem_cache_alloc(lsm_htable_cache, gfp_flags);
> > + if (!e2) {
> > + return -ENOMEM;
> > + }
> > +
> > + spin_lock(&lsm_spinlock);
> > + hlist_for_each(tmp, &lsm_hash_table[h]) {
> > + e = hlist_entry(tmp, struct lsm_cache_entry, list);
> > + if (e->ptr == ptr && e->lsm_id == lsm_id) {
> > + e->data = data;
> > + goto out_free;
> > + }
> > + }
>
> Two lock round trips per set.
Yes, that was pretty ugly.
> I'm pretty skeptical of this approach. I suspect the performance
> numbers will be enough to kill it.
A note on that:
I didn't include performance numbers this time because 2.6.9 by
itself performs significantly worse than the 2.6.8.1 I used for
the other approach. However, a previous prototype which I tested
under 2.6.8.1 came out a little better than the chaining approach,
and worse than the builtin approach.
I'm working on the improved chaining design which Stephen pointed
out I wasn't doing last time. Perhaps actually embedding the
list_head into the LSM security structures will bring its performance
above the hashing approach.
-serge
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 11:29:17 PDT