[..] > Willy and I were just chatting about this and I think the conclusion > we're coming to is that we'll probably want to try just RCU freeing > _everything_ at first, the reason being that anonymous pages are > probably going to get included and that may end up being most of the > allocations and frees - so why not just do everything. > > Meaning - _lots _of memory cycling through RCU, not bounded by device > bandwidth like I initially thought. > > Another relevant topic: https://kernelnewbies.org/MatthewWilcox/Memdescs > > The plan has been to eventually get an actual enum/type tag for our > different page types, and that would be really helpful for system > visibility/introspection in general, and in particular for this project > where we're going to want to be able to put numbers on different things > for performance analysis and then later probably excluding things from > RCU freeing in a sane standard way (slab, at least). > > I wonder if anyone wants to solve this. The problem with doing it now is > that we've got no more page flags on 32 bit, but it'd be _very_ helpful > in future cleanups if we could figure out a way to make it hapen. > > That'd help with another wrinkle, which is non compound higher order > pages. Those are tricky to handle, because how do we know the order from > the RCU callback? If we just don't RCU free them, that's sketchy without > the page type enum because we have no way to have a master > definition/list of "these types of pages are RCU freed, these aren't". > > Possibly we can just fake-compound them - store the order like it is in > compound pages but don't initialize every page like happens for compound > pages. (Not following the thread closely, sorry if this is completely meaningless) Why not store the metadata we need in the page itself, given that it is being freed anyway?
