On Thu, Apr 19, 2018 at 04:15:02PM -0400, Jerome Glisse wrote: > On Thu, Apr 19, 2018 at 12:56:37PM -0700, Matthew Wilcox wrote: > > > Well scratch that whole idea, i would need to add a new array to task > > > struct which make it a lot less appealing. Hence a better solution is > > > to instead have this as part of mm (well indirectly). > > > > It shouldn't be too bad to add a struct radix_tree to the fdtable. > > > > I'm sure we could just not support weird cases like sharing the fdtable > > without sharing the mm. Does anyone actually do that? > > Well like you pointed out what i really want is a 1:1 structure linking > a device struct an a mm_struct. Given that this need to be cleanup when > mm goes away hence tying this to mmu_notifier sounds like a better idea. > > I am thinking of adding a hashtable to mmu_notifier_mm using file id for > hash as this should be a good hash value for common cases. I only expect > few drivers to need that (GPU drivers, RDMA). Today GPU drivers do have > a hashtable inside their driver and they has on the mm struct pointer, > i believe hash mmu_notifier_mm using file id will be better. file descriptors are small positive integers ... ideal for the radix tree. If you need to find your data based on the struct file address, then by all means a hashtable is the better data structure.
