On 2019-04-10 18:35:21 [+0000], Yonghong Song wrote: > > Ah. I checked one or two of those and it looked like it was raw since > > the beginning. Anyway, it would be nice to Cc: the RT developer while > > fiddling with something that only concerns RT. > > > > That usage pattern that is mentioned in ac00881f9221, is it true for all > > data structure algorithms? In bpf_lru_list I was concerned about the > > list loops. > For some skewed hash tables with a lot of elements, yes, it is possible > time to traverse the loop could be a little bit longer... okay. So all that adds to your max latency which we try to keep low. If this is debugging only one could argue that it is okay. However if it is intended to be used in production then we usually try to keep as low as possible (i.e. have an upper limit). > > However hashtab and lpm_trie may perform memory allocations > > while holding the lock and this isn't going to work. > > The memory allocation in these two places uses GFP_ATOMIC which should > not sleep/block. That is not true for -RT usage. GFP_ATOMIC enables the usage of emergency memory pools (which are in general precious) and won't schedule() in order to free memory. This doesn't change on -RT. However, SLUB may call into the page allocator in order to get a fresh page and this is not working on -RT. This means you can't allocate memory from a preempt_disable() / local_irq_disable() section which includes your raw_spin_lock(). It works from spin_lock_irq() because that one is a sleeping lock on -RT. Sebastian
