lkml.org 
[lkml]   [2020]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/19] char_dev: replace cdev_map with an xarray
On Wed, Aug 26, 2020 at 10:19:05AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 26, 2020 at 08:24:28AM +0200, 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.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Really? This is ok to use and just as fast? If so, wonderful, it would
> be great to clean up kobj_map users.

Xarrays provide pretty efficient as long as we have a unsigned long
or smaller index (check, dev_t is small) and the indices are reasonable
clustered (check, minors for the same major). Memory usage will go down
vs the probes, and lookup speed up.

> > + mutex_lock(&chrdevs_lock);
> > + for (i = 0; i < count; i++) {
> > + error = xa_insert(&cdev_map, dev + i, p, GFP_KERNEL);
> > + if (error)
> > + goto out_unwind;
> > + }
> > + mutex_unlock(&chrdevs_lock);
> >
> > kobject_get(p->kobj.parent);
>
> Can't you drop this kobject_get() too?

I'll have to drop it or add back the put on the delete side. And
I think the latter is safer for now, because..

>
> And also the "struct kobj" in struct cdev can be gone as well, as the
> kobj_map was the only "real" user of this structure. I know some
> drivers liked to touch that field as well, but it never actually did
> anything for them, so it was pointless, but it will take some 'make
> allmodconfig' builds to flush them out.

I looked at it, but it does get registered and shows up in sysfs.
I don't really dare to touch this for now, as it can have huge
implications. Better done in a separate series (if we can actually do
it at all).

\
 
 \ /
  Last update: 2020-08-27 10:54    [W:0.090 / U:1.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site