On Thu, Mar 01, 2018 at 11:57:43PM +0000, Stephen Bates wrote: > > We don't want to lump these all together without knowing which region you're allocating from, right? > > In all seriousness I do agree with you on these Keith in the long > term. We would consider adding property flags for the memory as it > is added to the p2p core and then the allocator could evolve to > intelligently dish it out. Attributes like endurance, latency and > special write commit requirements could all become attributes in > time. Perhaps one more reason for a central entity for p2p memory > allocation so this code does not end up having to go into many > different drivers? I fear we will find that every kind of P2P memory has special allocator requirements and dumping it all into one giant pool is not going to be helpful. This allocator is already seems not useful for the P2P target memory on a Mellanox NIC due to the way it has a special allocation flow (windowing) and special usage requirements.. Nor can it be usefull for the doorbell memory in the NIC. Both of these are existing use cases for P2P with out of tree patches.. The allocator seems to only be able to solve the CMB problem, and I think due to that it is better to put this allocator in the NVMe driver and not the core code.. At least until we find a 2nd user that needs the same allocation scheme... Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
