Re: [v9.1] sepgsql - userspace access vector cache

2011/6/12 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Jun 9, 2011 at 3:09 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> Here is two level lookups.
>> The first is from object identifiers to security label; it can be boosted
>> using syscache mechanism. The second is from security labels to
>> access control decision; it can be boosted using userspace avc.
>
> OK.  Let's have two separate patches, then.
>
> Thinking a bit more about the issue of adding a syscache, I suspect
> it's probably OK to use that mechanism rather than inventing something
> more complicated that can kick out entries on an LRU basis.  Even if
> you accessed a few tens of thousands of entries, the cache shouldn't
> grow to more than a few megabytes.  And that's presumably going to be
> rare, and could happen with other types of objects (such as tables)
> using the existing system caches.  So I guess it's probably premature
> optimization to worry about the issue now.
>
> I would, however, like to see some performance results indicating how
> much the cache helps, and how much memory it eats up in the process.
>
The attached patches are separated ones.

The smaller one adds a new SECLABELOID syscache, and modifies
GetSecurityLabel() that uses syscache interface when supplied
ObjectAddress does not point to LargeObjectRelationId.

The larger one is control/sepgsql part; that adds cache mechanism
of access control decision.

I tried to measure performance with/without these patches.
The avc improved the cost to make access control decision
in all cases. In addition, syscache feature also improved
performance when pg_seclabel is not heavily updated.

* Test 1. time to run SELECT sepgsql_restorecon(NULL)
selinux | SECLABELOID syscache
avc | without | with
---------+---------+----------
without | 2.63[s] | 2.81[s]
---------+---------+----------
with | 0.60[s] | 0.59[s]
---------+---------+----------

The selinux avc efficiently improved performance, however,
the effect of syscache is unclear because this workload also
invokes updates of system catalog, so it might be a bottle-neck
of the benchmark.

* Test 2. time to run 50,000 of SELECT from empty tables
selinux | SECLABELOID syscache
avc | without | with
---------+-----------------------
without | 185.59[s] | 178.38[s]
---------+-----------------------
with | 23.58[s] | 21.79[s]
---------+-----------------------

So, I also measured the performance of read-only queries.
The SECLABELOID syscache also improved performance
nearby 10%, although it contains whole of the query parsing,
optimizing and executing.

Regarding to memory consumption, we don't worry about
consumptions by uavc, because it caches an entry for a pair
of security labels and object class. A particular security label
tends to be shared by large number of objects.
For syscache, length of a typical security label in selinux is
less than 64 bytes. If we assume an entry consume 128bytes
including Oid pairs or pointers, its consumption is 128KBytes
per 1,000 of tables or others.
(Do we have a way to confirm syscache status?)

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>