 I will give a topic about the BPF memory allocator introduced in 6.1, and the BPF memory allocator is owning contacts allocator for BPF program by XC, and here the owning contacts means process contacts, APU contacts, and even NMI contacts, and also the legacy contacts. It is used in the hash table and CPU, and there are other use cases, but first it is used in the hash map to make it usable for, sorry, I think it is not good, and during and when I was implementing the CPU try, I was trying to use, I was trying to use the BPF memory allocator but I found there are some problems with it, and the first problem is the immediately reused the problem, and this is the problem I am working on. The problem is now in BPF memory allocator, the freed element may be reused immediately, and the direct result is if the hash table using the BPF allocator, and if they are concurrently, if they are concurrently hash table lookup and deletion, the lookup may return incorrect result, and this is the result when I try to write a separate test for the hash map, and there are other influence include QP try may doesn't work correctly, and the reason is that the QP try includes the leaf loader and the interloader, because the inter, their point, their points in the interloader of the QP try, if the interloader is freed and is reused, the lookup in the QP try may be crushed, or it may panic the column, and I think the possible solution is trying to implement a new flavor of BPF memory allocator, it's called reused after GP, and the idea is from advocacy, it tries to reused, it reused the freed element after one SOGP, and freed after another task trace SOGP, so the freed element will not be reused, it will be reused after one SOGP, so the hash table lookup problems and the QP try will work correctly, but it have some bad effect, such as the memory usage will increase, I have pasted the result in the Bayesan patch set, or so the performance is degraded, except the only one have only questions? Are there any questions or comments currently not? Okay. Do you have do you have performance numbers from this V3, not yet? Oh, I pasted it in the patch set, I forgot to pasted it here, okay, I will go to the next issue, I have is to be done here, and the problem is the problem is now there is a BPF global memory allocator, and the first problem is it's a location from the root C group, so they can not limit its overall usage, because there's low limitation as root CG and root C group, and I'm not sure is there only need to free its memory during memory shrink, because for the BPF global memory allocator, it's a catch set, the multiple memory allocator catch is, so maybe I think is it okay, is it okay, is it okay to free, is it catch the element during the memory pressure, yeah, that's the first issue, and the other issue is because unlike the memory allocator in the hash table, the global memory allocator is there's a low destruction, and it will exist all the time, and now in the BPF allocator, there's only one pending framework back, so let's assume that if there's low framework on CPUX, the pending frame element on CPUX will not be freed, so it may be a problem, for now, for now the slumber system, there's a shrinker, they can add a shrinker for, there's a shrinker in the slumber system, so can we, could you, there's only need to add a shrinker for each BPF memory allocator, or the global memory allocator, so if there's a shrinker, so we can, we can try to, we can try to free, is catch the element during the memory pressure, I'm not sure, I'm not sure whether or not is there's a lidid, and for the, and for the second issue, I think maybe, maybe it's possible, maybe it's okay to start a time to check whether or not there is still freeable element after the counter as you call back is completed, and this is the issues of the BPF global memory allocator, but under the thing I want to discuss is whether or not this problem are okay, is not okay, whether or not this problem are solvable, is nothing to, is nothing to solvable. So my intake is like before I didn't shrinker, we need to measure with the memory that's sitting unused inside this global memory allocator, whether it's actually significant in any way, right, so it's supposed to be like in kilobytes, like last time I measured it was, because every per CPU free list was small, and watermark was like on average 32, so even if you have like 32 pages, that's well, yeah, 32 by 4, if you're bigger, but still it's still way less than the megabyte in memory, so like shrinking that doesn't seem that worth the code, but if it's a real issue, then yeah, we can definitely consider shrinker, but not sure what exactly it will do, right, what we discussed briefly, once we get to floating low and high watermark, then we would need some logic where it's like automatically adjust high low limits, and then we would need shrinker that would turn these limits down and will free the memory, so the memory that you saw while doing the benchmarking for the free after GP was all sitting in the color CU, color CU test trace callbacks, right, so shrinker will not help in this case, because this is memory anyway, they're just waiting for grace period to be freed, so that's not a shrinker job, shrinker can only look at free lists and potentially like free the memory from there, and only if this lists along, but currently they're like 32 on average, so that's like pretty small, so currently I don't see the need for shrinker. Yeah, I see, yeah, I will, I will try to measure the total memory of the BPF global MA first, yeah. And another point, yeah, another point you're making, which is also a good one, so it's the global MA, currently we did it on, yeah, it's global, it comes from the root CG, this is not great, and we've had a lengthy discussion on the mailing list, like what to do, like we try to introduce memory allocator as an object, as like some kind of special map type, and then the program will be able to select it, but then there are like issues with destruction, like who comes first and what is first, so we kind of punted this problem to later, we can like revisit this, if this is really an issue, it just like currently it seems to me there is no, yeah, not sure whether it's issue at all, that's yeah, until we measure it and see that is indeed the problem, yeah, it doesn't seem that worse, like adding a bunch of code to solve a potential issue. Okay, that's okay, that's the measure first, okay. I will move to the next and also the last issue, yeah, it's a problem of CPU hot plug, yeah, the reason why I found it, because I was trying to do some CPU hot plug during test, and I found it seems currently the BPF memory allocator doesn't do the CPU plug and the SLAMBO system data implementer, so should we implement the CPU plug for BPF MA allocate as well? What's an effect of it not being notified and not doing anything on the hot plug, so like for the case of hot plug, I can imagine that when the CPU is being removed, yeah, it's like the 32 elements by number of caches, so it's 32 by 11, whatever 300 elements of different sizes, they are not freed, so this is potential like waste when the CPU is going offline, but that's basically it, right, so that's the only issue I can see, it's yeah, some memory is wasted when CPU is offline, do you see any other issue here? Yeah, yeah, yeah, yeah, the waste is the major issue I think, yeah, yeah, but again let's measure what's exactly we're wasting, like how much memory is being wasted on average, like if it's again less than megabyte, is it really well I guess depends, right, if it's if it's if the amount of code that will just flash the free list is small, then yeah sure, makes sense to do, but then again like we've got to be careful because the MA doing this fancy, lockless stuff, so we don't like introduce more issues in the hot bus when we're doing the hot plug. Okay, okay, okay, I see a point, I call it a point, yeah, for now I don't have some really workload to test the memory waste of the CPU hot plug problem, yeah, yeah, and because as I said the major problem is the memory waste, so I think if it's there's low support, there's low hot plug support in BPF MA, it's okay as well, yeah, it doesn't have other problems, yeah, yeah, well, yeah, so just to be fair, like we don't have hot plug support anywhere in BPF and we have pre-allocated per-CPU things forever, just a regular HashMap, it's always like pre-allocated and pre-allocates on all CPUs and nothing frees those per-CPU free lists, so we probably have much bigger wastage in case of CPU being offline than this particular BPF MA, which is tiny compared to like a regular HashMap, like you have a regular HashMap, you have whatever 90 CPUs and it's a big whatever flow lookup HashMap that's consumed four gigabytes of memory, once CPU goes down that's significant, so that would be a bigger low hanging fruit if you really care about CPUs being offline for a very long time. Yeah, I say you point, but I think the problem of memory link is still a problem too fast, yeah. Okay, thanks. Okay, my presentation is over and there are only other questions. Thank you. Okay, thank you. Thank you.