Better linked-list traversal in BPF
Better linked-list traversal in BPF
Posted Mar 8, 2024 16:54 UTC (Fri) by willy (subscriber, #9762)In reply to: Better linked-list traversal in BPF by pj
Parent article: Better linked-list traversal in BPF
https://www.infradead.org/~willy/linux/scan.c
That doesn't actually do linked-list-by-index-instead-of-pointer. Someone who's interested can make that modification. But it's about 10x as fast to walk an array of random pointers as it is to walk a list of random pointers, depending on your CPU.
Posted Mar 8, 2024 17:48 UTC (Fri)
by epa (subscriber, #39769)
[Link] (6 responses)
if (curr->next == MAGIC) ++curr;
If the linked list is laid out mostly continuously in memory most of the time (perhaps not completely contiguous all of the time, because then you’d be using an array or vector instead) then the branch predictor should be able to learn the first case is more common and the code can run almost as fast as an ordinary loop over an array.
Posted Mar 8, 2024 18:14 UTC (Fri)
by mb (subscriber, #50428)
[Link] (2 responses)
if (curr->next == curr + 1) ++curr;
But I don't get why that would help.
I wouldn't be surprised if the compiler would optimize it into that.
Posted Mar 9, 2024 6:36 UTC (Sat)
by epa (subscriber, #39769)
[Link] (1 responses)
If the flag to say “just increment” were included in a part of the data structure you have to load anyway, then it might save some memory access too.
Posted Mar 9, 2024 18:08 UTC (Sat)
by Baughn (subscriber, #124425)
[Link]
This isn’t a new approach, by the way. LISP famously uses lists a lot, and LISP machines needed to process them quickly. Even with memory latency at the time being much lower relative to CPU speeds, laying them out contiguously in memory was a standard trick. One way to do that is to use a copying garbage collector, which if coded correctly will automatically defragment the lists when they’re copied.
Posted Mar 8, 2024 18:59 UTC (Fri)
by atnot (subscriber, #124910)
[Link] (2 responses)
* this goes beyond just performance implications but architectural decisions too. One of the "advantages" of linked lists is that list items rarely move once they get created. This inevitably leads to things like structures getting bloated with information really only needed by one user and people stashing long-lived pointers to objects on lists somewhere without really worrying about how long they'll stay valid for, which ossifies into the familiar pointer hell codebase where you're scared of changing anything because something might still be holding a pointer to it and 5% of your CPU time is refcounting. But I digress.
Posted Mar 9, 2024 15:51 UTC (Sat)
by adobriyan (subscriber, #30858)
[Link] (1 responses)
Userspace have a luxury of kernel doing equivalent of vmalloc for their std::vector's, but kernel have to deal with fragmentation.
Posted Mar 9, 2024 20:24 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Better linked-list traversal in BPF
else curr = curr->next;
Better linked-list traversal in BPF
else curr = curr->next;
You can just say curr = curr->next, because you need to load the next pointer anyway.
Better linked-list traversal in BPF
Better linked-list traversal in BPF
Better linked-list traversal in BPF
Better linked-list traversal in BPF
Better linked-list traversal in BPF