On Tue, 10 Dec 2013, Dave Hansen wrote: > > > > The single page struct definitions makes it easy to see how a certain > > field is being used in various subsystems. If you add a field then you > > can see other use cases in other subsystems. If you happen to call > > them then you know that there is trouble afoot. > > First of all, I'd really argue with the assertion that the way it is now > make it easy to figure anything out. Maybe we can take a vote. :) Its certainly easier than it was before where we had page struct defs spluttered in various subsystems. > We _need_ to share fields when the structure is handed between different > subsystems and it needs to be consistent in both places. For slab page > at least, the only data that actually gets used consistently is > page->flags. It seems silly to bend over backwards just to share a > single bitfield. If you get corruption in one field then you need to figure out which other subsystem could have accessed that field. Its not a single bitfield. There are numerous relationships between the fields in struct page. > > How do you ensure that the sizes and the locations of the fields in > > multiple page structs stay consistent? > > Check out the BUILD_BUG_ON(). That shows one example of how we do it > for a field location. We could do the same for sizeof() the two. A bazillion of those? And this is simpler than what we ahve? > > As far as I can tell we are trying to put everything into one page struct > > to keep track of the uses of various fields and to allow a reference for > > newcomes to the kernel. > > If the goal is to make a structure which is approachable to newcomers to > the kernel, then I think we've utterly failed. I do not see your approach making things easier. Having this stuff in one place is helpful. I kept on discovering special use cases in various kernel subsystems that caused breakage because of this and that special use cases for fields. I think we were only able to optimize slabs use of struct page because we finally had a better handle on what uses which field for what purpose. Looks to me that you want to go back to the old mess because we now have a more complete accounting of how the fields are used. It may be a horror but maybe you can help by simplifying things where possible and find as of yet undocumented use cases for various page struct fields? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>