On 6/23/20 4:45 AM, Greg Kroah-Hartman wrote:
Sure, but "help, I'm abusing your code interface, so fix your code
interface and not my caller code" really isn't the best mantra :)
Well, those are your words, not mine. What we're saying is, "we've
identified an interface that doesn't scale in this situation, but we
have a way to make it scale to all known configurations."
> I am offended as a number of years ago this same user of kernfs/sysfs
> did a lot of work to reduce the number of contentions in kernfs for
> this same reason. After that work was done, "all was good". Now
> this comes along again, blaming kernfs/sysfs, not the caller.
Ok. I don't know about the history, but I can tell you "blame" is not
the word I'd use. As hardware changes, Linux also changes, and over "a
number of years" it's not surprising to me if basic assumptions changed
again and led us back to a place we've been before. That's not an
indictment. It just IS.
> Memory is only going to get bigger over time, you might want to fix it
> this way and then run away. But we have to maintain this for the next
> 20+ years, and you are not solving the root-problem here. It will
> come back again, right?
If hardware vendors insist on dealing with small blocks of memory in
large aggregates, then yes it could. You'll have to trust that I am
also in discussion with hardware architects about how that is a very bad
architecture and it's time to change decades and think bigger. Separate
audience, equally contentious discussion. But the bottom line is, it's
out there already and can't be walked back.
Your response here seems to center on "kernfs was never designed for
that." If so, we're in agreement. We're suggesting a way it can be
extended to be more robust, with no (apparent) side effects. I'd like
to discuss the merits of the patch itself.
Rick
