On Thu, 2020-06-25 at 11:43 +0200, Greg Kroah-Hartman wrote: > On Thu, Jun 25, 2020 at 04:15:19PM +0800, Ian Kent wrote: > > On Tue, 2020-06-23 at 19:13 -0400, Tejun Heo wrote: > > > Hello, Rick. > > > > > > On Mon, Jun 22, 2020 at 02:22:34PM -0700, Rick Lindsley wrote: > > > > > I don't know. The above highlights the absurdity of the > > > > > approach > > > > > itself to > > > > > me. You seem to be aware of it too in writing: 250,000 > > > > > "devices". > > > > > > > > Just because it is absurd doesn't mean it wasn't built that way > > > > :) > > > > > > > > I agree, and I'm trying to influence the next hardware design. > > > > However, > > > > > > I'm not saying that the hardware should not segment things into > > > however many > > > pieces that it wants / needs to. That part is fine. > > > > > > > what's already out there is memory units that must be accessed > > > > in > > > > 256MB > > > > blocks. If you want to remove/add a GB, that's really 4 blocks > > > > of > > > > memory > > > > you're manipulating, to the hardware. Those blocks have to be > > > > registered > > > > and recognized by the kernel for that to work. > > > > > > The problem is fitting that into an interface which wholly > > > doesn't > > > fit that > > > particular requirement. It's not that difficult to imagine > > > different > > > ways to > > > represent however many memory slots, right? It'd take work to > > > make > > > sure that > > > integrates well with whatever tooling or use cases but once done > > > this > > > particular problem will be resolved permanently and the whole > > > thing > > > will > > > look a lot less silly. Wouldn't that be better? > > > > Well, no, I am finding it difficult to imagine different ways to > > represent this but perhaps that's because I'm blinker eyed on what > > a solution might look like because of my file system focus. > > > > Can "anyone" throw out some ideas with a little more detail than we > > have had so far so we can maybe start to formulate an actual plan > > of > > what needs to be done. > > I think both Tejun and I have provided a number of alternatives for > you > all to look into, and yet you all keep saying that those are > impossible > for some unknown reason. Yes, those comments are a starting point to be sure. And continuing on that path isn't helping anyone. That's why I'm asking for your input on what a solution you would see as adequate might look like to you (and Tejun). > > It's not up to me to tell you what to do to fix your broken > interfaces > as only you all know who is using this and how to handle those > changes. But it would be useful to go into a little more detail, based on your own experience, about what you think a suitable solution might be. That surely needs to be taken into account and used to guide the direction of our investigation of what we do. > > It is up to me to say "don't do that!" and to refuse patches that > don't > solve the root problem here. I'll review these later on (I have > 1500+ > patches to review at the moment) as these are a nice > micro-optimization... Sure, and I get the "I don't want another post and run set of patches that I have to maintain forever that don't fully solve the problem" view and any ideas and perhaps a little more detail on where we might go with this would be very much appreciated. > > And as this conversation seems to just going in circles, I think this > is > going to be my last response to it... Which is why I'm asking this, I really would like to see this discussion change course and become useful. Ian
