On Mon, Jan 11, 2021 at 06:20:29PM +0000, Matthew Wilcox wrote: > On Mon, Jan 11, 2021 at 07:11:25PM +0100, Greg KH wrote: > > On Mon, Jan 11, 2021 at 05:35:00PM +0000, Matthew Wilcox wrote: > > > On Mon, Jan 11, 2021 at 06:05:13PM +0100, Christoph Hellwig wrote: > > > > None of the complicated overlapping regions bits of the kobj_map are > > > > required for the character device lookup, so just a trivial xarray > > > > instead. > > > > > > Thanks for doing this. We could make it more efficient for chardevs > > > that occupy 64 or more consecutive/aligned devices -- is it worth doing? > > > > efficient in what way? Space or faster lookup? > > Both, but primarily space. > > The radix tree underlying the xarray allows N consecutive entries with > the same value to be represented as a single entry; if there are at > least 64 entries then we get to skip an entire level of the tree (saving > 1/7 of a page). Of course, we'd need to go from the 'head' pointer to > the correct pointer, something like p += rdev - p->rdev. How much "space" are you talking about here? A "normal" machine has about 100-200 char devices. Servers, maybe more, but probably not. The kobject being used previously wasn't really "small" at all, so odds are any conversion to not use it like this will be better overall. > > THis shouldn't be on a "fast" lookup path, so I doubt that's worth > > optimizing for. Space, maybe, for systems with thousands of scsi > > devices, but usually they just stick to the block device, not a char > > device from what I remember. > > /dev/sgX is a chardev? I sure hope no one is using /dev/sgX for tens of thousands of block device accesses, if so, they have bigger problems than this :) thanks, greg k-h
