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

2011/7/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>> Is it possible to only include the syscache on --enable-selinux
>> configurations? It would imply physical data incompatibility with standard
>> configurations, but that's also true for e.g. the block size.
>
> Not really.  SECURITY LABEL is supposedly a generic facility that can
> be used by a variety of providers, and the regression tests load a
> dummy provider which works on any platform to test that it hasn't
> gotten broken.
>
>> Also, the tests I did with varying bucket sizes suggested that decreasing
>> the syscache to 256 didn't show a significant performance decrease compared
>> to the 2048 #buckets, for the restorecon test, which hits over 3000 objects
>> with security labels. My guess is that that is a fair middle of the road
>> database schema size. Are you unwilling to pay the startup overhead for a
>> extra 256 syscache?
>
> Not sure.  I'd rather not, if it's easy to rejigger things so we don't
> have to.  I don't think this is necessarily a hard problem to solve -
> it's just that no one has tried yet.
>
Now, I tend to implement a cache mechanism to translate ObjectAddress
to security label by sepgsql module itself, rather than generic syscache,
although it requires a new hook on PrepareForTupleInvalidation() as Robert
suggested in this thread.
Indeed, it seems to me worthwhile not to allocate memory being unused for
90% of users; from perspective of startup performance and resource consumption.

In addition, we may be potentially able to have a cache stuff well optimized
to the access control of SELinux; such as cache reclaim for recently unused
entries. So, I'd like to focus on the stuff in sepgsql/uavc.c right now.

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