Re: [RFC 0/6] Backing Store for sysfs

Patrick Mochel
2003-10-06T20:33:54Z

> > That's what I told you, only reversed - try again. The patch posted in
> > unacceptable, though I'm willing to look at alternatives. I don't have or
>
> Viro's suggestion of pinning the non-leaf dentries only seems like
> a very good first alternative to try out.

Uh, that's about the same thing I suggested, though probably not as
concisely:

"As I said before, I don't know the right solution, but the directions to
look in are related to attribute groups. Attributes definitely consume the
most amount of memory (as opposed to the kobject hierachy), so delaying
their creation would help, hopefully without making the interface too
awkward.

You can also use the assumption that an attribute group exists for all the
kobjects in a kset, and that a kobject knows what kset it belongs to. And
that eventually, all attributes should be added as part of an attribute
group.."

Attributes are the leaf entries, and they don't need to always exist. But,
you have easy access to them via the attribute groups of the ksets the
kobjects belong to.

> > see a problem with the current situation, so your arguments are going to
> > have to be a bit stronger.
>
> By not pinning dentries, you save several hundreds of KBs of lowmem
> in a common case low-end system with six disks, much reduced number of dentries
> in the hash table and huge savings in large systems. I would hope that
> is a good argument. Granted you don't like Maneesh's patch as it is now,
> but those things will change as more feedbacks come in.

A low-end system has six disks? I don't think so. Maybe a low-end server,
but of the dozen or so computers that I own, not one has six disks. Call
me a techno-wimp, but I think your perspective is still a bit skewed.

I understand your argument, but I still fail to see evidence that it's
really a problem. Perhaps you could characterize it a bit more and
convince us that sysfs overhead is really taking up a significant
percentage of the total overhead while running a set of common
applications with lots of open files (which should also be putting
pressure on the same caches..)

Thanks,

Pat