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.. ;)
pgpV9E4AGbVnx.pgp
Description: PGP signature
-- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
