[redhat-lspp] NetLabel performance numbers

[Valdis.Kletnieks at vt.edu]

On Thu, 13 Jul 2006 14:25:07 EDT, Paul Moore said:

> > There's still something unexplained about that 625 for tcp_stream on C_FlCat.
> > Was either box hitting CPU saturation at that point?
> 
> Don't know for certain, I wasn't watching CPU usage since I wanted all
> the numbers to be as unmolested as possibile - I just kicked off the
> script and had a cookie.  Although I can say there is a lot of work that
> needs to be done in the "s0:c0.c239", i.e. full category, case and I
> wouldn't be surprised if the receive thread was maxing out a CPU core;
> look at the validation code in cipso_ipv4.c and the ebitmap_import()
> routine up in the SELinux code.  I both cases I tried to write code that
> didn't suck too badly but I haven't done any serious refinement either.
>  I suspect there is probably more speed to be gained but it is always
> going to be inherently painful.

Well, at least we *already* know where to start tuning. :)

The numbers look good enough that you probably want to push this to the netdev
list and Andrew Morton's -mm fairly soon - the code looks good enough for -mm
now, and you want to get it in there so it's been there a while before the
2.6.19 merge window opens.  Hopefully, further optimization can happen before
19-rc1 hits, but you want to get your foot in the door *soon*.

> The cache is not done per-connection, but rather per-label.  As it
...
> tweak it so I thought I would expose the knob.  In you opinion is using
> the slab mechanism a requirement?  It doesn't use it currently ...

Hmm.. probably not on a per-label basis - any given system is only going
to have a reasonably small number of labels that make sense on a network
connection, and new ones only happen on a policy load.  So we're not going
to be doing a lot of free'ing and reallocating. (Yes, these have the same
lifetime rules as an SELinux avtab_node - those only have a slab because
there's like 151K of them on my system, and you want to minimize the
pointer overhead.  203 per slab means a lot of pointers per-slab rather
than per-item.. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20060713/17cf1138/attachment.sig>