> > these all seem to be single-packet processing latencies - it would be> > quite hard to make those codepaths preemptible.> > I suspected as much, these are not a problem. The large latencies> from reading the /proc filesystem are a bit worrisome (trace1.txt), I> will report these again if they still happen with Q8.

conntrack's ct_seq ops indeed seems to have latency problems - the quickworkaround is to disable conntrack.

The reason for the latency is that ct_seq_start() does a read_lock() onip_conntrack_lock and only ct_seq_stop() releases it - possiblymilliseconds later. But the whole conntrack /proc code is quite flawed:

#1: we kmalloc(GFP_KERNEL) with a spinlock held and softirqs off - ouch!

#2: why does it do the kmalloc() anyway? It could store the position in the seq pointer just fine. No need to alloc an integer pointer to store the value in ...

#3: to fix the latency, ct_seq_show() could take the ip_conntrack_lock and could check the current index against ip_conntrack_htable_size. There's not much point in making this non-preemptible, there's a 4K granularity anyway.